jiebi/CodeConvo huggingface dataset:
Code change:
selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in <del> Section 11.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 8 of I- D.ietf-oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </del> <ins> Section 9.5 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 7 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </ins> claim of the SD-JWT MUST be used.

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:
selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in <del> Section 11.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 8 of I- D.ietf-oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </del> <ins> Section 9.5 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 7 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </ins> claim of the SD-JWT MUST be used.

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:
selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in <del> Section 11.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 8 of I- D.ietf-oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </del> <ins> Section 9.5 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 7 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </ins> claim of the SD-JWT MUST be used.

Related discussion:
text: and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL
Code change:
2. <del> Clients include the Tunnel-Protocol Request Header field in a HTTP Connect request to indicate the application layer protocol or protocols that will be used within the tunnel. </del> <ins> Clients include the `Tunnel-Protocol` Request Header field in an HTTP CONNECT request to indicate the application layer protocol will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.

Related discussion:
text: This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.
Code change:
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <ins> 6.2.2.3. The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID the peer can use when making subscriptions.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3. The server sends a "GOAWAY" message to initiate session migration

Related discussion:
text: Some diffs are due to me reflowing text to fit the line limits, so please ignore those. Once we have this and a limit on announce IDs, it seems likely that we'll be able to get rid of 'Role', but for now it can stay.
Thanks NAME . this looks like a good improvement. I have few clarification questions and bit of extra work for you to add some informative text, if my comment seems ok to you.
Unfortunately, that makes it much more difficult for the server to tell abusive clients from valid ones, as we discovered with the recent HTTP/2 rapid reset attacks. In the end we did develop heuristics, but they're imperfect and in the process we broke a bunch of applications in an effort to defend against DDoS attacks. In contrast, QUIC had a system like this and experienced no issues and we didn't need to develop any new heuristics.
Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit. The simplest idea would be to have a limit specified as a parameter in the server's SETUP message. As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?
rofl I just came here to post the same issue. See: URL I think we follow QUIC and have a MAXSUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends or (TODO). I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.
Also do we need ? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.
Code change:
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <ins> 6.2.2.3. The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID the peer can use when making subscriptions.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3. The server sends a "GOAWAY" message to initiate session migration

Related discussion:
text: A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: Announces also likely need some limits, but I'm less clear on how that might work.
I propose a monotonically increasing in the message. You can't reuse Subscribe IDs. We add a message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value. The corresponding messages use that ID instead of echoing the full track name. This removes ambiguity and overhead. We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example: Same for .
Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.
This is related to
may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..
As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAXSUBSCRIBEID frame to increase the limit, similar to QUIC flow control.
The consensus at the session today was to go with a QUIC style approach, so I wrote There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.
Will assign to Mike English
This seems like a really complicated way to limit the subscribes. I understand how it mirror streams but that had pretty different constrains. Why don't we just have an subscribe error of "too many subscriptions"? Discussed open issues in the 7 August 2024 virtual, not recorded here. Remaining issue (just do a SUBSCRIBE_ERROR?) went to the list and chairs declared rough consensus, although at least 2 participants would prefer not to have this.
Code change:
The "type" value is optional and defaults to "raw". <del> 2.1.7. </del> <ins> 2.1.6. </ins> <del> 2.1.7.1. </del> <ins> 2.1.6.1. </ins> A response that contained a response header:

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
3.2.3. <ins> An integer indicating the sequence of this catalog object update. The first catalog object produced under a given name|namespace carries a sequence number of zero.  Each successive update of that catalog, either as an independent or delta update, increments the sequence number by one. 3.2.4. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.4. </del> <ins> 3.2.5. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.5. </del> <ins> 3.2.6. </ins> A catalog object is a collection of fields whose location is specified as 'RC', 'TC' or 'RTC' in Table 1. <del> 3.2.6. </del> <ins> 3.2.7. </ins> A track object is a collection of fields whose location is specified as 'RT', 'TC' or 'RTC' in Table 1. <del> 3.2.7. </del> <ins> 3.2.8. </ins> <del> A number specifying the moq-transport object number from which this catalog represents a delta update.  See deltaupdate for additional details.  Absence of this parent sequence number indicates that this catalog is independent and completely describes the content available in the broadcast. </del> <ins> An optional integer specifying the catalog sequence number sequencenumber number from which this catalog represents a delta update.  See deltaupdate for additional details.  Absence of this parent sequence number indicates that this catalog is independent and completely describes the content available in the broadcast. </ins> <del> 3.2.8. </del> <ins> 3.2.9. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  The track namespace is required to be specified

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
If a Transparency Service is honest, then a Transparent Statement including a correct Receipt ensures that the associated Signed <del> Statement passed its Registration Policy and was recorded </del> <ins> Statement passed its Registration Policy and was registered </ins> appropriately. Conversely, a corrupt Transparency Service may:

Related discussion:
text: We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM
Code change:
The code in the browser initiates the authorization code flow with the PKCE extension (described in authorization_code_flow) (B) above, and obtains an access token via a POST request (C).  The JavaScript <del> app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs. </del> <ins> application is then responsible for storing the access token (and optional refresh token) as securely as possible using appropriate browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </ins> When the JavaScript application in the browser wants to make a <del> request to the Resource Server, it can include the access token in the request (D) and make the request directly. </del> <ins> request to the Resource Server, it can interact with the Resource Server directly.  It includes the access token in the request (D) and receives the Resource Server's response (E). </ins> In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to

Related discussion:
text: Arrow C is referenced in the text "[The code in the browser] obtains an access token via a POST request (C).". The arrow should have an arrowhead on both ends as it symbolizes both the token request and token response. "The JavaScript app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs." I think this sentence was misleading, because as of today there is no way for the app to store tokens securely in the browser. Arrow E was not referenced in the text.
Code change:
8.7. <ins> Holder binding aims to ensure that the presenter of a credential is actually the legitimate Holder of the credential.  There are, in general, two approaches to Holder Binding: Claims-based Holder Binding and Crpytographic Holder Binding. Claims-based Holder Binding means that the Issuer includes claims in the SD-JWT that a Verifier can correlate with the Holder, potentially with the help of other credentials presented at the same time.  For example, in a vaccination certificate, the Issuer can include a claim that contains the Holder's name and birthdate, and a Verifier can correlate this data with the Holder's passport that has to be presented together with the vaccination certificate - either as a digital credential or a physical document. Cryptographic Holder Binding means that the Issuer includes some cryptographic data, usually a public key, belonging to the Holder. The Holder can then sign over some data defined by the Verifier to prove that the Holder is in possession of the private key. Without Holder Binding, a Verifier only gets the proof that the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it.  This means that, for example, after a credential was leaked to an attacker, the attacker can present the credential to any verifier that does not require Holder Binding.  But also a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Holder Binding. </ins> Verifiers MUST decide whether Holder Binding is required for a particular use case or not before verifying a credential.  This decision can be informed by various factors including, but not

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity
Code change:
7. Transfer coding names are used to indicate an encoding transformation <del> that has been, can be, or might need to be applied to a payload body in order to ensure "safe transport" through the network.  This </del> <ins> that has been, can be, or might need to be applied to a payload's data in order to ensure "safe transport" through the network.  This </ins> differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.