jiebi/CodeConvo huggingface dataset:
However, I feel once we resolve fetch api, flow control and limits around handling large absolute ranges, we can revisit to see if groupId are still the issue or not.
Are logging and metrics the motivating use cases for multiple publishers of the same track? Reading the drafts, it doesn't appear like that is the intent, or you could get collisions. If you have any use cases like this, can you share them?
Individual Comment: Based on how SUBSCRIBE is defined now, I think both group IDs and object IDs have to indicate an ordering. If I SUBSCRIBE at a given start group and object, only published objects with groups numerically greater than or equal to that will be delivered. This is similar with SUBSCRIBE_UPDATE specifying the end of a subscription. Object IDs are also numerically comparable for prioritization within their group and priority level. There's text all over the draft implying these comparisons are valid, for example in stream-per-track, group IDs cannot go backwards. If an application wants to pick IDs at random, use a hash scheme, or dole out ranges to multiple publishers where newer things have numerically smaller IDs, then some funny interactions and protocol violations may ensue. No one has publicly specified a use case yet for doing this.
These are suggested changes for a quite trivial issue. Please, take a look at my explanation in URL for more details.
URL URL " An example successful response: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache" Pretty sure application/json shouldn't have a charset (see note at end of section URL) and I've long thought that "Pragma: no-cache" shouldn't be there (see URL ) Note that these apply to most of the example responses in the draft. Examples in RFC 6750 and RFC 6749 as well as some normative text in section of RFC 6749 use a "Pragma: no-cache" HTTP response header. However, both RFC 2616 and the shiny new RFC 7234 make special note along the lines of the following to say that it doesn't work as response header: 'Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.' The header doesn't hurt anything, I don't think, so having it in these documents isn't really a problem. But it seems like it'd be better to not further perpetuate the "Pragma: no-cache" response header myth in actual published RFCs. So with that said, two questions: 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response header inappropriately? 2) If so, does this qualify as errata?
Been working on this on and off for a while now (it's not exactly short at 80+ pages, various other priorities, etc.) but wanted to share my thoughts from an initial review of the OAuth 2.1 draft before the interim next week where it is on the agenda URL So for better or worse, here's that review: Abstract: "replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749." I think "replaces" is probably unnecessary here and, to be pedantic, is arguably inaccurate because published RFCs don't ever go away or get replaced.
Probably should also consider using the official "obsoletes" attribute marker too for 6749 URL and probably also "updates"/"obsoletes" for others based on the scope of the rest of the document (not sure how this even works with a BCP or if you can or would want to update or obsolete a BCP) if this work proceeds. That scope could be better described in the abstract too as discussed somewhat in the thead URL and also the 1st paragraph of URL What is and isn't in scope is another larger question that I"m not even sure how to ask. What's included vs. what's referenced? Should this doc be incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda antithetical to what a BCP is supposed to be but it's also a bit hard to tell how much was used. I mean, what happens if/when the BCP is updated? And that kinda begs the question of if it should also incorporate parts of or even replace the browser based apps draft? I guess that's a TBD circa page 68. There was talk about the device grant being in scope but I'm not seeing it (not saying it should or shouldn't be there but it was talked about). I dunno exactly but those are some scope questions that come to mind. Speaking of obsoleting, I do want to ensure that existing extensions and profiles of RFC 6749 that use legitimate extension points still present and unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm not sure how that should work in practice but want to be aware of it as/if this work progresses. URL "is designed for use with HTTP ([RFC2616])." I was momentarily proud of myself for knowing that RFC 2616 is obsolete but then remembered that the nits tool can automate the check for other obsolete or problematic references URL so take a look at those issues. Probably should also check the errata of any documents this one intends to update/obsolete or just borrowed a lot of text from to see if anything should be applied. URL "The interaction between the authorization server and resource server is beyond the scope of this specification."
Don't want to try and change the scope but perhaps a mention that things like RFC 7662 Token Introspection and self-contained tokens a la JWT exist here (or sec 1.4 or 7 or...) would be worthwhile. URL " Steps (3), (4), (5), and (6) are outside the scope of this specification, as described in Section 7." But Section 7 incorporates parts of RFC 6750 so being out of scope isn't really true. URL Not too sure about this section in this document but seems that it should at least reflect the fact that some things like RFC 8414 Authorization Server Metadata do now exist. URL All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days. URL Mentioning the existence of RFC 7591 Dynamic Client Registration here seems appropriate. And I think it's be super useful to say that even when RFC 7591 isn't being used directly, it (and registered extensions to it URL) imply a common general data model for clients that's pretty widely used and useful even with so called static registration that "typically involve end-user interaction with an HTML registration form." URL "Authorization servers SHOULD NOT allow clients to influence their "clientid" or "sub" value or any other claim if that can cause confusion with a genuine resource owner." This text taken from draft-ietf-oauth-security-topic is out of context and somewhere between meaningless and confusing here in this document. Removing it or maybe something like this might be more appropriate: "Authorization servers SHOULD NOT allow clients to influence their "clientid" value in such a way that it might cause confusion with the identifier of a genuine resource owner during subsequent protocol interactions." URL "The client MAY omit the [clientsecret] parameter if the client secret is an empty string." Let's remove that sentence. As Michael Peck noted in his review, it doesn't even make sense in the context of this section describing authentication of confidential clients using a password/client secret. And that sentence has been the source of some other problems.
More detail is in this thread URL URL "Other Authorization Methods" should be "Other Authentication Methods" It's probably worthwhile to note or reference the other client authentication methods that have been specified since this text was written in 6749 and/or point to the OAuth Token Endpoint Authentication Methods registry URL for them and also maybe mention that, despite the Token Endpoint in the name, they are general methods of client auth to the AS when making direct requests. URL "The means through which the client obtains the location of the authorization endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation." Maybe add something like "or in the authorization server's metadata document [RFC8414]." "Request and response parameters MUST NOT be included more than once." please clarify that sentence to say: "Request and response parameters defined by this specification MUST NOT be included more than once." URL " The authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986], Section 6.2.1." There's absolutely no context here for understanding what two URIs are being compared. Mandating full redirecturi comparison is maybe more appropriate in 4.1.1 with the redirecturi parameter somewhere. And 3.1.2.3. and 3.1.2.2 needs some attention with respect to this too. But also an exception (for the port part) to full redirecturi comparison is needed for loopback redirecturis on native clients as in URL and URL and URL URL As Michael Peck noted in his review, it's probably okay now to just mandate TLS for HTTP redirect URIs. Although custom scheme or loopback redirect URIs for native apps wouldn't use or require TLS. URL and URL Seem to still allow for registration of partial redirection URIs. Which isn't gonna work with an exact match requirement. URL "Request and response parameters MUST NOT be included more than once." please clarify that sentence to say: "Request and response parameters defined by this specification MUST NOT be included more than once." " The means through which the client obtains the location of the token endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation." Maybe add something like "or in the authorization server's metadata document [RFC8414]."
URL "Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full." Isn't full registration of redirection URI now required (other than maybe the port for native apps) by virtue of requiring a full comparison be done when validating the authz request? And other than a native app using the loopback, maybe it's time to move to require that redirection URIs be accessed via secure channel? URL "Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and know via out-of-band configuration that the server supports "plain"." With codechallengemethodssupported from Authorization Server Metadata / RFC 8414 it doesn't have to be out-of-band anymore. URL " Typically, the "codechallenge" and "codechallengemethod" values are stored in encrypted form in the "code" itself but could alternatively " 'Typically' - really? URL " ensure that the "redirecturi" parameter is present if the "redirecturi" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical." The reference should be to 4.1.1.3. URL " An example successful response: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache" Pretty sure application/json shouldn't have a charset (see note at end of section URL) and I've long thought that "Pragma: no-cache" shouldn't be there (see URL ) Note that these apply to most of the example responses in the draft. URL " specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "granttype" parameter" The words in the parenthetical have led to questions in AD review of documents making use of the grant type extension point (see https://mozphab-URL) and I think "understood by the authorization server" might be better phrasing or even removing the parenthetical all together. RFC7522 is mentioned here as an example extension grant but maybe worth also including mention of others like RFC7523, RFC8628, RFC8693, and maybe even non IETF ones.
URL " Sender-constrained refresh tokens: the authorization server cryptographically binds the refresh token to a certain client instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]." Given the relative immaturity of ways to do this, maybe something more open ended would be appropriate? This reads like token-binding or MTLS are the only ways allowed. I'd think wording that would allow for DPoP or some yet-to-be-defined method would be better here. Also maybe drop the token-binding reference all together (it's long expired and doesn't look like that's gonna change). URL The SHOULDs/RECOMMENDEDs in this section seem a little overzealous and/or too specific. URL Seems to be a lot of overlap and duplication between 9.4. Access Tokens (under 9. Security Considerations) and section 7.4. Access Token Security Considerations, which could/should maybe be reconciled. "(#poptokens)" hints that some text was copied from elsewhere but the markdown references weren't fixed/updated URL "(#refreshtokenprotection)" same thing about markdown references not fixed/updated URL "(#insufficienturivalidation)", "(#mixup)", "(#openredirectoronclient)","(#csrfcountermeasures)", again "(#mixup)", and "(#redirect307)" URL "Attacker A4 in (#secmodel)" "The use of PKCE is RECOMMENDED to this end." PKCE is required elsewhere so this doesn't seem quite right. Similar comments about text ijn URL that talks as though PKCE might not be there. URL "(#rediruriopenredir)" URL "(#clientimpersonating)" URL " * Redirect URIs must be compared using exact string matching as per Section 4.1.3 of [I-D.ietf-oauth-security-topics]" Should that maybe be qualified to cover dynamic ports on ephemeral local http servers used for redirect URI with native clients? BTW, does [I-D.ietf-oauth-security-topics] need to make a similar allowance? URL "TBD" Given the potentially high visibility of an OAuth 2.1 effort, I think it'd be worthwhile to list organizational affiliations of individuals here in the acknowledgements along with their names.
Something like what was done in the first part of URL This can help with visibility and justification of (sometimes not insignificant) time spent on the work by non-authors/editors. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.
OK with me.
Display Strings are a superset of Strings, which are a superset of Tokens. This makes APIs more complex, and makes designers have to think about which structure to use. A couple of thoughts: 1) Should we define best practice, that e.g., you should specify Token or String when you specify String -- similar to HTTP? 2) Should we define a new TokenOrString type to encourage this pattern (both in header definitions and APIs)?
Not sure it would be always a best practice, but there are certainly cases where it is. Thus describing the pattern and making it easier to use it sounds right to me.
I'm probably missing something, but why would we want header designers to use TokenOrString? Given, as you say, string is a superset, if you needed to use a string, why allow tokens too when you can just define the header to simply take string?
For brevity. It happens in legacy header fields all the time (dunno whether that's a good reason, though).
This is because legacy fields didn't actually believe token and string are different types, right? Just that strings were optionally unquoted when you don't need quotes. But guidance on the types is for new fields. And, for better or worse, structured fields went with a data model where quoted and unquoted are different types, rather than alternate encodings of the same types. Now that we've made them different, if you're making a new field that needs to represent string values, use strings. It's true this means designers must pick between two similar types. Perhaps making them different was a mistake. (Though making them the same would mean multiple encodings, which is differently bad.) But we've already done that. It's too late to fully merge them because we'll break everyone who was told structures fields was ready to use and treated them differently. Without fully merging them, generic structured fields APIs are stuck using different types for them. So merging them back needs to be a per-field thing, which means fighting with your SF APIs. Instead, the best simplification we can manage is to discourage the TokenOrString half-measure in new fields and say you should just use one or the other.
To the first half of the bug, yes definitely define best practice!
Just if the best practice we pick does not align with the data model we picked, we have done something seriously wrong.
We already have best practice about Display Strings in the spec (in that we steer people away from them if they don't need them). We have a separation between Tokens and Strings because they were visible on the wire in pre-existing headers, and we wanted to be able to retrofit / 'pave the cowpaths'. In some cases, they are interchangeable; in others, they are not. I suspect that if we documented best practice for new fields, we'd say "probably use Strings most of the time" because of the underlying reason I raised this issue for -- APIs have very natural mappings for Strings, but for Tokens you probably need some sort of wrapper object or equivalent strategy, so that you can distinguish them from Strings. I'll put together a PR nudging people that way.
Sounds good! So I guess the decision tree is then: Do you need display strings? If yes, use that and only that. Do you have a legacy reason to use tokens? If use, do whatever your legacy reasons need. Otherwise, just use ASCII strings.
HTTP Methods have 3 boolean properties, all of which says a registration needs to define, but only "Safe" and "Idempotent" were included in the registry while "Cacheable" was omitted. I filed this as URL, but it probably makes more sense as a change for ter.
I think the only concern I have here is that people often misinterpret "cacheable" - e.g., see .
FWIW, that's because it isn't a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics. I'd prefer to remove that from the registration table. We could still require that the registration describe how and under what conditions the method semantics might be cacheable.
It's not in the registration table, and I tend to agree it should be kept out for the reasons above.
This was discussed regarding Variants, and I think the answer will be the same; we should record this sort of thing in documentation elsewhere, e.g., the .
URL says but then the method definitions themselves seem to consistently say After this discussion, I think the method definitions ("The response is cacheable") are more correct, and that therefore my initial suggestion in this erratum is incorrect. URL repeats the less-correct form by listing "cacheable" along with "safe" and "idempotent" as properties of the method. I think removing "cacheable" from that list, and changing "If the new method is cacheable, ..." to something like would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?
Note that RFC7540 Section 8.2 relies on that distinction by saying that pushed requests MUST be cacheable in order to be pushed, but conditionally defines what happens if the delivered response does turn out to be cacheable. Eliminating the distinction entirely would leave 7540 slightly unmoored.
I think the proposed edit to considerations for new methods is helpful; we could address the 7540 concern by parenthetically adding "also known as cacheable methods" or similar. Note also the first bullet of . If we can come up with a better phrase than "defined as cacheable" that's great, but it needs to be distinct from response cacheability.
See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.
This is confusing; hopefully this rewrite is a little less so. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM