jiebi/CodeConvo huggingface dataset:
Code change:
In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs in the browser.  This application is considered a public client, <del> since there is no way to issue it a client secret and there is no other secure client authentication mechanism available in the browser. </del> <ins> since there is no way to issue it a client secret and authentication is handled by the application, not by the browser. </ins> The code in the browser initiates the Authorization Code flow with the PKCE extension (described in authorization_code_flow) (B) above, <del> and obtains an access token via a POST request (C).  The JavaScript application is then responsible for storing the access token (and </del> <ins> and obtains an access token via a POST request (C). The application is then responsible for storing the access token (and </ins> optional refresh token) as securely as possible using appropriate <del> browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </del> <ins> browser APIs. </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it can interact with the Resource

Related discussion:
text: reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)
Code change:
4.4. <del> The recipient of the SD-JWT VC MUST process and verify an SD-JWT VC as follows: </del> <ins> The recipient (Holder or Verifier) of an SD-JWT VC MUST process and verify an SD-JWT VC as described in Section 6 of I-D.ietf-oauth- selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in Section 9.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 6 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the claim of the SD-JWT MUST be used. For the verification, the claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in jwt-issuer-metadata) of the SD-JWT VC issuer.  Alternative methods MAY be used to obtain the public key to verify the signature of the SD-JWT. If there are no selectively disclosable claims, there is no need to process the claim nor any Disclosures. If is present in the verified payload of the SD-JWT, the status SHOULD be checked.  It depends on the Verifier policy to reject or accept a presentation of a SD-JWT VC based on the status of the Verifiable Credential. </ins> Any claims used that are not understood MUST be ignored.

Related discussion:
text: We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.
Code change:
version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the <del> same connection.  It also introduces unsolicited push of representations from servers to clients. </del> <ins> same connection. </ins> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

Related discussion:
text: NAME says: It's not very widely used and many implementations either don't support it at all or don't support it in a way that improves end-user performance. This sparked a lively discussion at URL
I’m open to dropping this, but I think the case needs to be be made for what the burden is. It’s one of the easiest protocol features to just ignore: send SETTINGSENABLEPUSH=0 and then you can remove all awareness of PUSH_PROMISE from your state machine altogether.
Crazy thought: what if we made part of HTTP/2, and then factored server push into an extension?
Or what if we minted a new ALPN () and flipped the default value?
Or left it as is, since it is used outside of browsers. The browsers have an API problem that has not been solved, and it is unlikely that push will be effective there (except as a competitor to inlining) until that changes.
I have no particular objection to flipping the default under a new ALPN. Factoring it out to an extension is harder, but not impossible -- it's pretty embedded in the state machine, but we might be able to abstract that away. Removing it entirely seems challenging for several reasons. The purely process one is that RFC 8030 requires Server Push, and removing a feature used by a Standards Track RFC presumably requires deprecating that other RFC.
I should note that my preferred outcome here is "do nothing". I'm just spitballing ideas.
Flipping the default if we mint a new alpn seems sensible based on the comments above. This would also align with HTTP/3. Moving it to an extension is probably more work than it's worth, I'll admit. I wasn't aware of RFC 8030. Is that an actively used RFC?
Push is being used outside of browsers (curl supports it, once implemented for a particular company that uses/used it pretty widely across the globe), although I suspect that outside of browsers we also have no real means of figuring out exactly how much or little. Saying "do it in extension" will probably equal killing it, but I also think that removing it from the spec is more work than its worth and just toggling the default seems like the best middle ground.
We may want to be a bit relaxed about flipping the default.
Code change:
version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the <del> same connection.  It also introduces unsolicited push of representations from servers to clients. </del> <ins> same connection. </ins> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

Related discussion:
text: As the setting is client-only the default value never really exists on a connection: the client’s SETTINGS are the first frame it sends. The reason to flip the default is to save 6 bytes on all connections. This is not nothing, but it’s not a huge win either.
I agree that it's not worth changing anything here, except if we want to be sure to cause some confusion between implementations. The first frame sent is the one indicating support (or lack thereof) by the client. Maybe we should just add a paragraph in the PUSH section mentioning that 5 years after the relerase, PUSH has still got very low adoption among implementations and should not be assumed as a granted feature for protocols sitting on top of H2.
I think NAME suggestion of adding a note about deployment and not expecting wide support would be very helpful. My biggest concern with keeping it in the spec is that people will expect it's widely supported and its use is recommended for most use cases.
Feeling here seems to be supportive of no normative changes, but possibly some editorial additions clarifying the status of push. If you feel otherwise, please say so soon.
SGTM. FYI, Chrome is expected to drop support for HTTP/2 server push in the= near future and has never implemented push for HTTP/3.
NAME has it been announced somewhere? I can't find it.
Several popular web frameworks actively use Server Push including (mostly for assets) and (for API relations). Server Push is also (currently) supported by most browsers as well as by NGINX, Apache and Caddy. On the APIs field, , which aims to replace GraphQL-like document compounding is also gaining adoption, and rely on Server Push (even if it can fallback on preload Link headers and Early Hints too). I just published a benchmark showing how useful Server Push is for the specific use case of web APIs. Under certain conditions, relying on it can be 4x times faster than using compound documents: URL As pointed in martinthomson/http2v2, for these use cases, Server Push could be replaced by Early Hints or maybe by something using WebTransport, but these specs aren't currently implemented while Server Push is broadly available. Removing support for Server Push in Chrome will hurt all this use case. What's really missing with HTTP/2 Server Push is a way to prevent pushing resources already stored by the client.
Code change:
version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the <del> same connection.  It also introduces unsolicited push of representations from servers to clients. </del> <ins> same connection. </ins> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

Related discussion:
text: could have been a solution, but the work on it looks stopped.
URL
NAME suggested calling out the current status: lack of support in browser APIs for push, pointy edges in the usage, and the limitations in the spread of its usage. I think this is a reasonable editorial change.
NAME to draft a document to encourage users to set the value to 0 by default and move on.
Discussed at Feb 2021 interim; intent to document concerns / caveats, recommend sending setting = 0. NAME to PR.
LGTMVery nice. Thanks Mark.
Code change:
must succeed.  Compliance and requirement checking includes audits of the results of organizational procedures and technical procedures, which can originate from checks conducted by the organization itself <del> or checks conducted by trusted third parties.  Consecutively, </del> <ins> or checks conducted by trusted third parties.  Consequently, </ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include:

Related discussion:
text: I believe this is a typo, but perhaps I misunderstood the intended meaning.
Good catch, NAME Thanks for the PR
LGTM
Code change:
URN Namespace for IETF Use [2] somehow.  Or maybe nothing.  Or maybe something else. <ins> TODO: "tth" and maybe "oth" claim in JSON Web Token Claims Registry [3] </ins> 6.1. TODO: "application/wimse-id+jwt" or appropriately bikeshedded media type name (despite my ongoing unease with using media types for <del> typing JWTs) in Media Types [3]. </del> <ins> typing JWTs) in Media Types [4]. TODO: "application/wimse-proof+jwt" ... </ins> 6.2. TODO: "Workload-Identity-Token" from <ins> TODO: "Workload-Proof-Token" from </ins> 7.  References 7.1.  URIs

Related discussion:
text: [8:31 AM May 30 in slack] To summarize the near term plan: Joe: security considerations and interaction with TLS Brian: ID Token and DPoP-inspired Yaron: Message Signatures this is the "DPoP-inspired" part A preview editors' copy of this PR can be seen at URL
Code change:
EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended. <del> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested. </del> Subscriber Priority: Specifies the priority of a subscription relative to other subscriptions in the same session.  Lower numbers get higher priority.  See priorities.

Related discussion:
text: This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.
Code change:
3.2. <ins> The server issues workload identity credentials when requested by the Agent. </ins> 3.3. <del> The identity is provisioned to the workload as a set of credentials. There are two main types of workload credentials: bearer tokens and X.509 certificates. </del> <ins> The Agent performs the function of transmitting the initial workload identity to the Server to obtain the workload identity credentials. The Agent makes the workload identity credentials available to the workload. A task scheduler installs and starts a task containing the Agent on the Host Operating System.  A Host Operating System function performs attestation of the Agent-identity and issues a corresponding Agent- credential to the Agent.  The Agent presents the Agent-credential together with the Workload Identity to the Server to obtain the Workload's Identity Credentials. 3.4. Attestation is the function through which a task verifies the identity of a separate Workload or task. During Workload Attestation, the Server verifies the Agent- credential, Workload Identity, and the permission of the Agent to receive Credentials authenticating the Workload Identity.  The Server can use a variety of means to verify that permission, including a Policy decision based on the contents of a Workload Registration database or requesting assistance from a trusted Identity Provider. 3.5. The Agent provisions the identity credentials to the workload.  There are two main types of workload credentials: bearer tokens and X.509 certificates. </ins> Bearer tokens are tokens presented to another party as proof of identity.  They are typically signed to prevent forgery, however

Related discussion:
text: added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.
Code change:
interoperability across different implementations of Transparency Services with various auditing and compliance requirements.  Issuers can register their Signed Statements on any Transparency Service, <del> with the guarantee that all Consumers will be able to verify them. </del> <ins> with the guarantee that all Auditors and Verifiers will be able to verify them. </ins> 1.

Related discussion:
text: Related mailing list thread: URL
these changes make sense to me
As part of , I would like to consider the removal of Consumer and consumer from this specification if we are not going to define it. It is a generalized term and I would rather expend work group time on trying to tailor an appropriate custom definition of it. I will likely post this issue to the mailing list and cross-reference that thread here and leave this issue for review for a week to solicit feedback. Related mailing list thread: URL
I do think Producer and Consumer is a good generic concept, with more clearly defined roles as Relying Party, Verifier, and Auditor, however, I'd support replacing Consumer with Relying Party or Verifier.
But we do not define them nor cite references that do. From a formality and procedures perspective in IETF, is that OK? Thanks for the feedback.
LGTM with some comments to accept/reject Hello, I have been reviewing the specification and there are usages of Consumer(s) as a specific term to be defined in the draft and consume/consumer(s) generically. The use of the term consumer is ill-defined and I would support not consuming time ahead of 119 defining it. Therefore, I am proposing that we remove the capitalized term and some generic usage of it for clarity. I welcome feedback on the pull request to alter or critique specific, individual changes (207), the issue to track the work for more general discussion (206), or in the form of replies in this thread on the mailing list. URL URL If I do not hear back in one week and there is no objection in the pull request, the issue, or mailing list, I will follow up and ask the authors to merge (if it has not been merged already). Thanks in advance for your review and any feedback you provide. Thanks, A.J.
Code change:
'RC' - the field may be located in either the Root or a Catalog object. <del> 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object. </del> <ins> 'TFC' - the field may be located in either a Track object, the Common Track Fields object or a Catalog object. </ins> <del> 'TC' - the field may be located in either a Track object or a Catalog object. </del> <ins> 'TF' - the field may be located in either a Track object or a Common Track Fields object </ins> <del> 'RT' - the field may be located in either the Root or a Track object. 'T' - the field is located in a Track object. </del> <ins> 'T' - the field is located in a Track object </ins> 'S' - the field is located in the Selection Parameters object.

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
The normative requirements for the prefixes are detailed in the storage model algorithm defined in storage-model. <del> This is because some servers will process cookie case-insensitively, </del> <ins> This is because some servers will process cookies case-insensitively, </ins> resulting in them unintentionally miscapitalizing and accepting miscapitalized prefixes.

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
Error Code: Identifies an integer error code for announcement failure. <del> Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for announcement error. </ins> 6.13.

Related discussion:
text: When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR
Code change:
contain at least one byte of padding and a 16 octet authentication tag. <del> Each record contains between 1 and 256 octets of padding, inserted </del> <ins> Each record contains between 2 and 65537 octets of padding, inserted </ins> into a record before the enciphered content.  Padding consists of a <del> length byte, followed that number of zero-valued octets.  A receiver MUST fail to decrypt if any padding octet other than the first is non-zero, or a record has more padding than the record size can accommodate. </del> <ins> two octet unsigned integer in network byte order, followed that number of zero-valued octets.  A receiver MUST fail to decrypt if any padding octet other than the first two are non-zero, or a record has more padding than the record size can accommodate. </ins> The nonce for each record is a 96-bit value constructed from the record sequence number and the input keying material.  Nonce

Related discussion:
text: This is a proposal to address issue /cc NAME
I've updated the graph in section 2 to note the new range. PTAL.
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
The following is a non-normative example of the contents of an SD- JWT-R for Example 1: <del> For each claim, an array of the salt and the claim value is contained in the </del> <ins> For each claim, a JSON literal that decodes to an object with the and the claim value (plus optionally the claim name) is contained in the </ins> object.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
serialization. Let byte_array be the result of applying UTF-8 encoding (Section 3 <del> of UTF8) to input_sequence. </del> <ins> of UTF8) to input_sequence.  If encoding fails, fail serialization. </ins> Let encoded_string be a string containing "%" followed by DQUOTE.

Related discussion:
text: I guess that's the best we can do, considering that Unicode is a minefield. :-/
... in a swamp.
Is it worth dealing with the fact that 3629 doesn't actually define how to encode a sequence of characters, but we're calling it with one? We'd need to add something to this text, like "for each character (or code point?) in inputsequence, append the result of applying UTF-8 encoding to character to bytearray".
currently does not consider what happens when UTF8 serialization fails, although this could happen with surrogate points. I believe it should explicitly say that. Alternatively, the introduction of display strings could say that only unicode scalars (URL) are allowed (but even then I'd add the extra precaution in the serializer). Finally, we may want to add an example because all of this is far from obvious.
NAME and NAME pointed out that URL doesn't define the and operations that this draft uses. RFC 3629 only defines a character at a time. RFC 3629 also doesn't say to fail encoding or decoding in any particular situations. It says "The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF", but its definition of encoding doesn't actually prohibit those characters. It also says "MUST protect against decoding invalid sequences", but the definition of decoding doesn't fail in that case. URL is more explicit on these questions and might therefore be a better reference.
Note that the recommended entry points for other specs are URL which are clear about how to handle BOMs as well.
Seems reasonable - will try to work up a PR. I'm likely to keep the general reference to 3629 for UTF-8, and use encoding for the specifics.
I would very very very much prefer not to have a normative reference on a "living" document here. Let's just add the missing needed on top of RFC 3629 to this spec. (and yes, I can make a concrete proposal)
We were clear how to handle BOMs, but what you suggest is a change on top of that.
See minimal PR.
(Posted on the PR by accident:) Is it worth dealing with the fact that 3629 doesn't actually define how to encode a sequence of characters, but we're calling it with one?