jiebi/CodeConvo huggingface dataset:
Code change:
will not complete the authentication experience for the 1st party native application. <del> 9.5.2. </del> <ins> 9.6.2. </ins> In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses. <del> 9.5.3. </del> <ins> 9.6.3. </ins> To address these risk, when multiple 1st party native applications must be supported, and other methods such as OpenID.Native-SSO are

Related discussion:
text: I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.
Code change:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This <del> digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.

Related discussion:
text: [x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too
Code change:
This document defines the urgency("u") and incremental("i") parameters.  When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values <del> were specified.  Note that handling of omitted parameters is different when processing an HTTP response; see merging. </del> <ins> were specified. An intermediary can combine signals from requests and responses that it forwards.  Note that omission of parameters in responses is handled differently from omission in requests; see merging. </ins> Receivers parse the Dictionary as defined in STRUCTURED-FIELDS. Where the Dictionary is successfully parsed, this document places the

Related discussion:
text: Addresses Eb of . Bob highlights the actor is unclear. This attempts to address that in a minimal way without going too far down the rabbit hole of intermediaries.
Code change:
There is no standardized way to: enable the consumer to verify that software originated from a <del> 'duly authorized signing party' on behalf of the Supplier. </del> <ins> 'duly authorized signing party' on behalf of the supplier and is still valid. </ins> 3.2.

Related discussion:
text: Addressing issue and
This fixes issue and issue
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM
Code change:
11.2. <ins> URN: urn:ietf:params:oauth:token-type:self_signed Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section subject-token-types of this specification 11.3. </ins> Claim Name: "azd" Claim Description: The authorization context details

Related discussion:
text: Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.
Code change:
for the <del> . </del> <ins> .  A successful response reflects the quality of "sameness" identified by the target URI (RFC3986).  Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a response. </ins> GET is the primary mechanism of information retrieval and the focus <del> of almost all performance optimizations.  Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.  A successful response reflects the quality of "sameness" identified by the target URI.  In turn, constructing applications such that they produce a URI for each important resource results in more resources being available for other applications, producing a network effect that promotes further expansion of the Web. </del> <ins> of almost all performance optimizations.  Applications that produce a URI for each important resource can benefit from those optimizations while enabling their reuse by other applications, creating a network effect that promotes further expansion of the Web. </ins> It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of

Related discussion:
text: LGTM.
Need to explain or reference explanation.
LGTM.
okay, I think this reads better, or we can split them into separate PRs if needed
Code change:
not include content, the Content-Length indicates the size of the selected representation (field.content-length). <ins> A sender MUST NOT send a Content-Length header field in any message that contains a header field. </ins> 6.3. The length of a message body is determined by one of the following

Related discussion:
text: Good point.
I guess all the options are ugly. Should we leave the text wehre ut was and just apply the proposed change in URL ?
Does better belong in -messaging?
Into 6.2?
Seems like the best place, yeah.
NAME : URL
But I don't know what this accomplishes given the paragraph after this one also refers to Transfer-Encoding.This makes sense on its own (with Martin's adjustment). Still not thrilled about having transfer-codings in semantics.Thanks. Fairly simple fix here. I've suggested a tweak for Roy's concern (which I can't make a suggestion before because of GitHub limitations.
Code change:
corruption incidents.  These incidents include cache poisoning attacks.  Three mechanisms are suggested for mitigation of this risk: <del> Clients should ignore immutable for resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </del> <ins> Clients SHOULD ignore immutable from resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </ins> <del> User-Agents often provide two different refresh mechanismss: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, should ignore immutable as well. </del> <ins> User-Agents often provide two different refresh mechanisms: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, SHOULD ignore immutable as well. </ins> <del> Clients should ignore immutable for resources that do not provide </del> <ins> Clients SHOULD ignore immutable for resources that do not provide </ins> a strong indication that the stored response size is the correct response size such as responses delimited by connection close.

Related discussion:
text: Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this
Code change:
below. Some digest-algorithms, although registered, rely on vulnerable <del> algorithms: the "md5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "sha" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> <ins> algorithms and MUST not be used: "md5", see CMU-836068 and NO-MD5; "sha", see IACR-2020-014 and NO-SHA1. See the references above for further information. </ins>

Related discussion:
text: references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!
Code change:
authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. <del> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> 2.1.

Related discussion:
text: Removes a duplicated section from the introduction
Feedback from Brian Campbell: Section 2 repeats itself with the text "A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange. The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B. The client in domain A may be a resource server, or it may be the authorization server itself." occurring twice.
Code change:
otherwise intended.  The server MAY only support a limited number of methods. <del> The request MUST include the "Upload-Incomplete" header field (upload-incomplete).  It MUST be set to true if the end of the request body is not the end of the upload.  Otherwise, it MUST be set to false.  This header field can be used for request identification by a server.  The request MUST NOT include the "Upload-Offset" header. </del> <ins> The request MUST include the "Upload-Complete" header field (upload- complete).  It MUST be set to false if the end of the request body is not the end of the upload.  Otherwise, it MUST be set to true.  This header field can be used for request identification by a server.  The request MUST NOT include the "Upload-Offset" header. </ins> If the request is valid, the server SHOULD create an upload resource. If so, the server MUST include the "Location" header in the response

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
refresh token to obtain new access tokens potentially without being detectable by the authorization server. <del> Browser-based applications provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these applications are considered a higher risk for handling refresh tokens. </del> <ins> Javascript-accessible storage mechanisms like _Local Storage_ provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these mechanisms are considered a higher risk for handling refresh tokens. </ins> Authorization servers may choose whether or not to issue refresh tokens to browser-based applications. oauth-security-topics describes

Related discussion:
text: reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)
Code change:
it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. <ins> One of those mappings requires introduction of a new Structured Fields data type, Date. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data

Related discussion:
text: I still believe this change should end up in the revision of SF.
That's
Some have pushed back on using integers for dates, see eg URL As I suggested there, one accommodation would be to define a new structured type for them. That could be done in retrofit, or separately.
I see no mention of fractional seconds ? I think we need to ponder that, if the goal is (eventual) convergence for all timestamps in HTTP ? Considering how much effort we spend on speeding up HTTP, I find the "human readable" argument utterly bogus. Only a very tiny fraction of these timestamps are ever read by humans, and most are in a context where software trivially can render the number in 8601 format if so desired. In terms of efficiency, I will concede that, in a HTTP context, it is almost always possible to perform the necessary calculations and comparisons on raw ISO-8601 timestamps, without resorting to the full calendrical conversions, but once all the necessary paranoia is included, I doubt it is an optimization. My preference is seconds since epoch, (and this is largely why has three decimals in the first place), because it gives us fast processing, good compression and millisecond resolution. PS: A Twitter poll with only 40 respondents, carried out on the first monday after new-years ? Really ?!
One argument against any "seconds since epoch" representation is that (at least under the ) it is incapable of representing an instant within a positive leap second (since "each and every day shall be accounted for by exactly 86400 seconds_", any such time would be interpreted as being in the first second of the following UTC day).
For HTTP I think subsecond precision is an overkill due to RTT / intermediaries.
IMHO: I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable. I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ.
Code change:
it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. <ins> One of those mappings requires introduction of a new Structured Fields data type, Date. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data

Related discussion:
text: Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation. I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO. I do like the leap-second argument. I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.
Seems reasonable to me. +1 Not sure this is an "interface" that HTTP exposes / should be relied upon.
I suspect the experience of pretty much everybody writing and deploying HTTP intermediaries and servers at scale is different -- at those rates, cycles wasted on parsing do matter, especially when architectures have many layers of intermediaries to go through.
See linked PR for a proposal.
Re leapseconds: as written ("excluding leap-seconds") means that timestamps will be illegal, effectively mandating POSIX leap-second (non-)handling. To make able to handle leap-seconds requires that every HTTP handling entity needs an up to date file, either at system level or application level, and that the upper limit on the "internal data model range" becomes indeterminable, since we cannot predict how many leap seconds will happen in the future, nor what sign they may have. That is a total no-go from a systems engineering and complexity point of view, in particular as the rest of the world converges on either papering over leap-seconds or abolishing them. If the textual format cannot handle leap-seconds (without requiring a boat-load of complexity), then, why take the extra expense in CPU-load and code complexity ? As stated earlier, we should go for the more efficient and less error-prone solution: POSIX time_t (with optional milliseconds) as a .
Code change:
it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. <ins> One of those mappings requires introduction of a new Structured Fields data type, Date. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data

Related discussion:
text: (If we want to designate the timestamps with a senteniel, 'NAME is a particular bad choice, since the HPACK huffmann assigns it 13 bits.) PS: In context of four digit years: Century scale predictions, based on orbital considerations, expect the current leap-second regieme to break down in approx 2000 years, because we will need leap seconds more often than every month.
Do any current HTTP implementations take leap seconds into account? Regarding HPACK - it's one character. Let's not over-optimise here.
I don't know, but leap seconds are explicitly supported by : And the difference between 23:59:60 and following-day 00:00:00 would certainly be relevant for e.g. Last-Modified.
I have spent a lot of time over the years searching, but I have yet to see a 23:59:60 timestamp in the wild...
Now there's a picture in my mind of PHK walking the wilds, searching for an elusive date stamp.
I don't know what counts as "in the wild", but there is certainly documentation of and .
Discussion at IETF114 wasn't conclusive, but we now seem to be focusing on these options: Do nothing. Dates in SF are Integers (unless folks fall back to Strings), and recipients need to know that they're dates and how to handle them. Create a Date SF type along the lines of the PR. The textual representation is human-friendly, and it's identified as a date in a machine-readable way without special knowledge. Create a Date SF type but use an Integer; e.g., . The textual representation is not human-friendly, but it is identified as a date in a machine-readable way without special knowledge. I'll observe that if we believe that we'll eventually have a binary representation of structured fields widely in use, (2) is preferable in that it has the best properties -- it's both efficient and human-friendly. Of course, that's not at all certain. I'll also observe that in the discussions I've had, the people who want human-friendly representation are generally those who are working with tools and developers, "closer" to the application. The infrastructure folks and "lower layer" folks tend to minimise this aspect.
PR updated to reflect (3) above.
I personally support (2) or because it covers similar use cases than HTTP-date.