see URL and URL
oh wow... I apparently didn't confirm the merge so this is still pending. I really thought it was done and published -11. Sigh. Sorry. Will look at doing a -12 soonish.
see
Thanks for these additional updates. Michael B. Jones, Sir, I have endeavored to reply inline below to the remaining comments and/or addressing them with further updates to the source of the draft, which will appear in the -11 revision that hopefully will be published soon. I have the honor to be Your Obedient Servant, B. Cam remain consistent with that. But will expand the text defining Holder to better accommodate its use throughout the document. possible" line of reasoning, the use of the words "array elements" to mean array elements is the most concise and meaningful terminology the document authors were able to conceive of to convey the concept of elements in arrays. I believe it would be a disservice to readers to embellish the wording. a different misunderstanding at play here... and Terminology", sufficient and appropriate for the mention of a piece of terminology established by convention in a previously published RFC. 5.3. DPoP/RFC9449 is actually a complete sentence and this draft will be fixed so that it will also have a complete sentence. 5.3.2. the cnf claim the way to enable key binding with that increased interoperability as a primary aim. factually incorrect. The current wording might not be as descriptive as you'd like but it is correct. In what way does the encoding make it not a SHA-256 Hash? Asking rhetorically. opinion, that supports the assertion that any of that is "best practice". There are two occurrences of "[like or such as] nbf, iat, and exp" in the draft. In URL they are mentioned in the context of "claims carrying time information", which is what they all are. In URL they are mentioned in the context of claims to check regarding the validity of the SD-JWT. The "nbf" claim, as you likely know from (I think?) having written the text in RFC7519 , has normative requirements around when the "JWT MUST NOT be accepted for processing." As such, it is entirely appropriate in the context of mentioning some validity-controlling claims. The only normative requirement on the "iat" claim , however, is about the syntax of its value. Rejecting a token based on the "iat" value can be required by a specific profile of JWT, such as was done in DPoP, but is otherwise something that is at the discretion of an implementation/deployment and something that has apparently been the cause of some interoperability problems . Arguably "iat" shouldn't be in that list. 10.7. belong in this list. place of content omitted from the main payload. The ellipsis is often used in place of content omitted from the context at hand. 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.
Thanks very much for addressing the majority of my comments and for replying to the rest of them. I’m replying inline to the remaining ones that I believe should still be addressed. I’ve deleted the ones from this thread that I’m satisfied with the responses to. Best wishes, -- Mike From: Kristina Yasuda Sent: Wednesday, August 14, 2024 6:07 AM To: Brian Campbell Cc: Michael Jones ; EMAIL Subject: Re: [OAUTH-WG] Re: Review of draft-ietf-oauth-selective-disclosure-jwt-10 Thank you very much, Mike. Majority of your comments have been incorporated in this PR URL, which has been merged. Below, in bold, please find explanations for the points that have not been reflected. We appreciate your review. Best, Kristina Introduction: The usage of “Holder” in “used a number of times by the user (the "Holder" of the JWT)” inconsistent with its usage in the definitions, which defines “Holder” as being “an entity”. The usage here in the introduction makes the holder into a person rather than an entity. Please adjust the language here to not confuse the user who utilizes the holder with the holder itself. -> Holder is defined as an entity and a person can be considered an entity. We also have a phrase "the user (the "Holder" of the JWT)" in the introduction. Hence the editors consider the current wording to be sufficient. Since “Holder” is sometimes used in the spec to refer to the Wallet software and sometimes used to refer to the person using the Wallet, I believe that readers would be well served to make a clear terminological distinction between the two. Introduction: In “"Claims" here refers to both object properties (name-value pairs) as well as array elements.” change “array elements” to “elements in arrays that are the values of name/value pairs” (or something like that). Without saying what the array elements are, readers will be confused about what’s being referred to. I’d apply this clarification in 4.1. SD-JWT and Disclosures and other applicable locations as well. -> There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". The fact that a misunderstanding is possible and occurred leads me to believe that a clarification of this phrase is needed. Readers won’t necessarily know where the “array elements” being referred to occur in the data structures. That was certainly my experience, hence my initial comment. Possible wording that’s simpler than my initial proposed wording could be “array elements occurring within Claim values”. Or clarify it with different wording of your choosing. Feature Summary: In “A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name-value pairs) and array elements”, consider expanding “array elements” in the same manner as the preceding comment to make the meaning more evident. -> same as above. There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". Same response as my previous comment. 1.2. Conventions and Terminology: I suggest moving the “base64url” definition to the Terms and Definitions section and use a parallel structure to that at URL Specifically, say “The “base64url” term denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].” Then introduce the rest of the definitions with the phrase “These terms are defined by this specification:” as is done in RFC 7519. The current presentation is fairly jarring. -> Current text already points to Section 2 of RFC7515. The editors consider the current definition sufficient and clear enough. Yes, the definition is clear, but it’s in the wrong place. Definitions belong in the Terms and Definitions section. The current location leaves it strangely hang in a different section by itself, separate from the other definitions in the spec. Key Binding JWT: Change “MUST NOT be none.” to “It MUST NOT be "none".”. -> Changed to “It MUST NOT be .”. it is exactly the same wording as in DPoP RFC. The current wording is a sentence fragment – not a complete sentence. The fact that that error slipped through in DPoP isn’t a reason not to correct it here. 5.3.2. Validating the Key Binding JWT: In “if the SD-JWT contains a cnf value with a jwk member, the Verifier could parse the provided JWK and use it to verify the Key Binding JWT.”, change “could” to “MUST”. Make this normative to increase interoperability! -> the sentence you point at is an example, so we cannot add a normative statement here. We changed "should" to "would" to reflect the intent behind the suggestion. OK. Please address this then by adding this normative sentence at an appropriate place in the specification. “When the SD-JWT contains a cnf value with a jwk member, this key MUST be used to very the Key Binding JWT.” 6.1. Issuance: There are many places from here on where the label “SHA-256 Hash” is used, for instance “SHA-256 Hash: jsu9yVulwQQlhFlM3JlzMaSFzglhQG0DpfayQwLUK4”. Change all of these to “Base64url-Encoded SHA-256 Hash” for correctness. -> Editors consider it to be sufficiently clear from the specification text that it is a base64url-endoded hash. This would also require changes to the tooling and might unintentionally make the examples harder to read. The fact remains that the current wording is factually incorrect and therefore needs to be corrected. If this can be done by updating the tooling, that’s actually good, since it means that it will be consistently corrected everywhere the error occurs. Verification of the SD-JWT: Delete “nbf” from “claims such as nbf, iat, and exp” and everywhere else in the spec, other than in 10.7. Selectively-Disclosable Validity Claims, where both “iat” and “nbf” should be listed, as described in my comment there. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. -> "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. Sure, it’s an example, but the examples should nonetheless reflect best practices. Please delete “nbf” here. 10.7. Selectively-Disclosable Validity Claims: Add “iat (Issued At) to the validity claims list before “nbf”, and change “nbf (Not Before)” to “nbf (Not Before) (if present)”. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. Change all uses of “nbf” to “iat” elsewhere in the spec. -> same as above. "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. As above, the examples should reflect best practices. Please at least add “iat” to this list, even if you choose to retain “nbf”. Everywhere: Consider changing the name “…” to something more indicative of its function, such as “sdelement” or “sd_item”. Or alternatively, at least provide rationale for why that non-obvious name was chosen. -> we have extensively bikeshedded this claim name, and this one was chosen because it is concise and natural since '...' is what is used when something is omitted in a list. there seems to have been some misunderstanding how disclosure in the arrays work, so hopefully with the clarifications above, this claim also feels more appropriate than before. I wouldn’t say that there’s a misunderstanding in how disclosure in arrays work. Rather, I’d say that the current exposition of array disclosure can leave readers wondering what is meant, and could be improved by the suggested clarifications above. Thank you for explaining that “…” is intended to be understood as the ellipsis character, and the intuition behind it. Its usage in that way is slightly odd, since the ellipsis character is used in place of omitted content, whereas in this case it’s used with the opposite meaning to introduce content that is NOT omitted (content that is disclosed). Be that as it may, I understand very well the reasons for keeping the claim name as it is. Nonetheless, I think it would be helpful to readers to add a comment when the claim name is introduced about why this otherwise non-obvious claim name was chosen. The sentence you add could be something like “The claim name “…” was chosen because the ellipsis character, typically entered as three period characters, is used in contexts where content is omitted (not disclosed).” Or choose your own wording. Give readers the intuition behind the choice. Finally, this comment was incompletely addressed: Section 11.1. Storage of Signed User Data: Please change “OpenID Connect” to “OpenID Connect [OpenID.Core]” (adding the missing citation). Best wishes, -- Mike


Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw. if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition


resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name


Despite or maybe in light of some recentish discussion on the mailing list, the topic seems like it deserves more prominent placement.


to
As far as I know, the idea of burning private keys to facilitate repudiation or reduced data value didn't resonate with any of the audiences for whom it was intended. I think the document would be better off without the paragraph copied below from URL And we might avoid some potentially difficult/confusing/painful/etc conversations in various latter stage IETF process steps.
I'm told that my statement that it "didn't resonate with any of the audiences for whom it was intended" might be premature.
I agree with deleting the text about publishing private keys. Yes, it's a technique that could be used with SD-JWTs but it's in no way specific to SD-JWTs. It could be used with normal JWTs, CWTs, SAML tokens, X.509 certs, etc. It doesn't add to the specification to describe this here.
leaving this open with no action for the time being because, as Dr. NAME says, "it's complicated".
agreed to remove.


URL and I don't know why my response isn't on the mail archive yet but here's a copy: !
oh hey that's fun:
sadness addressed in 9b7ad2d010e0f49e3dd8b5833c59fe4642e2892b (on the surface anyway)
isn't part of this duplicate of ?
Yeah, I did it here first just to fix things. Then decided fixing the build process should be decoupled from addressing one more of Mike's previous review comments.
Now overcome by events. I'm going to resurrect exactly one of my previous review comments that was not addressed. The original comment was: Issuance: There are many places from here on where the label "SHA-256 Hash" is used, for instance "SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4". Change all of these to "Base64url-Encoded SHA-256 Hash" for correctness. Brian responded "The current wording might not be as descriptive as you'd like but it is correct." I'll water down my request if you're not willing to change all the occurrences to "Base64url-Encoded SHA-256 Hash" to then please at least add a textual caveat before the first such occurrence along the lines of: In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". As I said in my initial review, I look forward to this specification being published as an RFC. Best wishes, -- Mike From: Rifaat Shekh-Yusef Sent: Tuesday, September 3, 2024 3:39 AM To: oauth Subject: [OAUTH-WG] WGLC for SD-JWT All, As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by Sep 17th. Regards, Rifaat & Hannes


URL
Danke! Thanks Neil, That is indeed an error. Thanks for catching that. We'll get it fixed. I see how that other part is a bit confusing too and will look at improving how those pieces flow together. And also maybe fix some other stuff in that area while we're at it, like inadequate salt length in at least one of the disclosures in 5.2.3. On Wed, Sep 4, 2024 at 9:17 AM Neil Madden wrote: 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.


From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. 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.


should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"


No good nit goes unaccepted
In Section 4.1.1 Hash Function Claim it's stated that: I've seen this reference and similar phrasing in other recent specifications and it's never indicated whether these values are case-sensitive or not. Perhaps this is fault of RFC 6920 not being explicit on the matter, but being vague here creates interop issues; I've already witnessed one regarding this very claim. Should these values be considered case-sensitive or not?
I guess it doesn't say so explicitly but the intent is absolutely that the values be considered case-sensitive. We can maybe add a brief statement to that effect.
adds one sentence indicating case-sensitivity.
Excellent, thank you!
Just for clarification, are sha-256 and SHA-256 different claim?
yes, sha-256 and SHA-256 are different
Good Thank you :)
assuming my small nit gets accepted


Issue and . Describing the concept of holder binding and giving minimum directions on: find pubKey in SD-JWT Sign SD-JWT-R using privKey bound to a pubKey in SD-JWT but leaving details to the profiles and implementations.


In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.


feat: Minimum length of the salt feat: weak hash algorithms to not use
mh ... we already have in Section
NAME I commited your suggestion I'm not sure that the normative language could be used in the considerations but it's good anyway to me, it's intellegibile :)


changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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.


updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL


Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.


Added text to address issue regarding the value of the claim within the Txn-Token
From Yaron's
Text from Yaron's email: : I think txn should be OPTIONAL. While it is very useful, there may be architectural reasons why transaction ID issuance in an organization is independent of transaction tokens.
I'm curious to the use cases? I'd prefer a way to make the claim REQUIRED and allow an organization to provide it's own value in that context. Maybe we could go with RECOMMENDED? This is one of those cases where people who know what they are doing can potentially remove it or possibly provide a "N_A" value and it will be fine. However, if it's OPTIONAL most developers will not specify the value and then they will lose a lot of value from the Transaction Token.
No specific use cases, it's just that we're assuming that an organization can easily integrate its (preexisting) transaction ID-issuing service with this one. Sometimes it can, sometimes it can't. I'm good with RECOMMENDED.
NAME please review PR which addresses this issue


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.


We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.


The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments


The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"


Is there a reason why you did not use uppercase terms like MUST NOT or SHOULD? Because it's supposed to be informative?
Yes, the section is non-normative.
Currently logging guidance says "Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII)". I have few questions on this one Risks with logging is that token is still valid for few minutes and if logs are rotated to any other central archival storage with access to broader set of people or someone has access to the server with logs, then they can reuse the token. So why not just say MUST not log token? Also how would a service know if incoming token has PII or not. They will have to validate the token, extract claims and then somehow know infer that a claim is PII or not. On similar lines, for PII , can we mention that TTS SHOULD evaluate encrypting or tokenizing PII claims rather than adding them in plaintext. Adding in plaintext is a risk because TTS isn't aware where the token flows.
Txn-Tokens already contain the subject identifier which is enough to be considered PII in some environments. Our own policy states that PII data can be logged, but the logs must be deleted after a few days (max 7) days. We forbid logging of Txn-Tokens in our integrations for security reasons, not just because they could contain PII.
Our implementation in my company, we do follow the same guidance i.e do not log tokens at all, nothing to do with PII. Tokens are pretty much considered as credentials as validating parties leverage the claims for authorizing the request.


See issue Question for reviewers. Do we need the final sentence on how a workload is invoked? If the sentence was not there would it change how we think about a trust domain? Do we need the second sentence as an example? Should we add more examples (e.g. trust domains can be defined as all the applications or workloads that recognise a specific issuer).
The definition of a Trust Domain feels very specific to network segmentation. Is there a industry level Trust Domain definition we can use instead? For example, should we use a definition that defines the trust domain in terms of the shared policies that apply? Something like: "A trust domain refers to a collection of systems, applications, or workloads that share a common security policy".
I'm good with this


Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this


See issue
In section 2.2.1 the context that may be included in a transaction token includes "The external authorization token (e.g., the OAuth access token)". To ensure this is not interpreted to mean that an access token is included in a transaction token, I would suggest the following additions, in line with section 9.3 in Security Considerations: "A reference to the external authorization token (e.g., the OAuth access token), including scopes or claims included in the authorization token, but not the unmodified authorization token (see Security Considerations, Section 9.3)"
Pieter, in that section of the spec we are describing what needs to be sent to the Transaction token service, I think in that case the full access token should be passed. However, when generating the request context, we want to ensure that the full access token is not included. Did I get my spec sections wrong?
Maybe instead we shouldn't say "This context MAY include:" but rather ... "The information provided to the Txn-Token Service MAY include" to not confuse readers who might think this data should be included in the request context.
Agreed - I missed that this was for initial token creation. I did create a PR with your suggested text.
PR approved
Looks good.


See issue
Good practice is to explain why something is a MUST. Suggestion: From: The value of the aud claim MUST remain unchanged in a replacement Txn-Token. To: The value of the aud claim MUST remain unchanged in a replacement Txn-Token to prevent the Txn-Token from being accepted outside it's current Trust Domain. Alternatively, we cann add security considerations for the draft as well.
I'm good with that text.
I think the current PR is making the change in the wrong place (unless I'm horribly mistaken)
Looks good


In response to Updated section on: Mutual Authentication Security Considerations for Client Authentication Added security considerations for protecting the workload configuration NAME NAME
I wonder if we can clarify the guidance in Section 7.4 a bit: From: It SHOULD rely on mechanisms, such as Spiffe or some other means of performing MTLS [RFC8446], to securely authenticate the requester. To: It SHOULD rely on JWT or X.509 credentials, which may be provisioned using SPIFFE or other mechanisms, to securely authenticate the requester. The final sentence in section 7 probably also needs a bit of clarification: It SHOULD rely on mechanisms, such as [Spiffe], to securely authenticate the Transaction Token Service before making a Txn-Token Request. I think the requirement here should be that the Transaction Server should be authenticated to the workload using a JWT or X.509 certificate, which may be provisioned using SPIFFE or another mechanism and used with a secure protocol like MTLS or using the WIMSE service-to-service authentication mechanisms.
I think clarifying this would be good (Section 7.6:) For me the key is that any workload invoking the TTS must use some form of strong client authentication. That could be SPIFFE, privatesecretjwt, mTLS, ??? The normative requirement should be "strong client authentication" and the others can be examples of such. I'm not sure how the workload can "pre-authenticate" the TTS. I like the pre-defined endpoint (or maybe "pre-configured" endpoint) concept. Basically, the TTS should be at a well known location. I guess there is a security issue if the workload sends an accesstoken to the wrong server especially if the external accesstoken is a bearer token. Is this something we should just cover in the Security Considerations section?
I think you touch on a few things here: We don't address discoverability of transaction token servers. Should we add something (e.g. define a well known endpoint, include discovery metadata in the authorization server metadata etc?) Can you say more about "pre-authenticate"? Do you mean some mechanism whereby the workload can trust the TTS or the location of the TTS? Agreed on the security considerations for ensuring that the access token is not sent to an incorrect endpoint (I can imagine an adversary getting into a build server, modifying the TTS location for a workload, and then have the TTS send tokens to it. I can also imagine this happening by accident, especially if there are multiple TTS's in a deployment.
Regarding the second point: Yes, should there be a way for the workload to determine it can trust the TTS before sending it an external token? This isn't something that is common in OAuth specs. It is assumed that the client knows whether to send the request or not.
Regarding 1: I think we wanted to talk about it at the last IETF and ran out of time. I seem to remember a few conversations around "discovery" but nothing concrete was decided.
I found the issue it's


Addresses issue - clarifying the value for when requesting a replacement Txn-Token
In : Does this assume that should be ? Should we call it out explicitly?
Yes, I think that makes sense.


We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager


Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL


Based on discussion and feedback in the IETF 117 Session, I've split the single flow diagram into three different flow diagrams.


The current draft had a request parameter named "azc" and also the claim within the TraT is called "azc", which leads to confusion whether the request parameter content is directly embedded into the token. So I am renaming the request parameter to "rctx".
Ahh... I think this parameter is for cases where the requestor wants to add some specific authorization data into the overall TxTkn. I would prefer to rename the parameter 'authz_details' which would be a JSON object and then add it as a sub-object in the of the TxTkn.
From Dr. Kelley W. Burgin Section 6.2: What does the AS do with the values in “azc”? Are they included in the transaction token? Can I put anything I want in “azc”?


is already registered (URL). Do we need to register it again? I'm not sure what the guidance here is.
I believe we should add an IANA consideration to propose the registration of azc claim. A list of registered claims can be found here: URL
I believe we should add an IANA consideration and propose to register .
Thanks for this email and adding the issues to GitHub. I will update the spec shortly.
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Looks good to me


See issue
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417


Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations


Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.


I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.


Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.
PR raised a number of issues around processing of authorization details How are these details determined by the Transaction Token Service (i.e. where do they come from)? Should all the claims be visible to all workloads? or should they be restricted to a subset of workloads? Who is authoritative for specifying the claims of the object
Some thoughts: I think the spec should be un-opinionated about how the TraT service generates the value of claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control. A TraT service could implement selective disclosure, although we could recommend in the spec that one should implement it by encrypting certain fields. Stating this makes the actual mechanism for selective disclosure outside the scope of the spec. I believe the TraT service MUST be authoritative for the claims of the object, because it is signing the TraT.
Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio. Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting object and whether it should be protected in some way or not. I am curious to hear from others as to their thoughts.
Suggestion to rename to and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the object into claims in the object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
I suspect in many cases the AS that issues an accesstoken used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself. Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the object. Should we require this format? or just leave out of scope of the specification what values are present in the claim of the transaction token?
I would definitely not require that format. And would again suggest that RFC 9493 isn't needed in the Txn-Token context and good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the claim is determined. In that context, I think the Transaction Token should carry the issuer of the claim which means the default and claims of the JWT are not sufficient. Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of , is the Transaction Token Service the correct issuer of the which is an email address?
I feel like there might be an undue emphasis on a relationship between and that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer URL but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the and the such that the globally unique identification is the combination of and . I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the claim MUST be unique within the single trust domain as identified by the claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true? I can see the TTS being authoritative for the single trust domain but not necessarily for the identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion... 'iss' claim is optional be clear that there is no relationship between iss and sub claim sub is unique within context of the 'aud' or trust domain go back just supporting the claim (no sub_id)
Added a new commit to PR to address this issue.
A few months ago, I also suggested to support the sub claim as per JWT RFC. As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Hi Kai, Thanks so much for your input in this process. Atul
Since we have removed sub_ids now, I will close this issue.
Wkn


Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"


See meeting notes here where we agreed to remove this: URL
The language in section needs to refer to the RFC and specify how to use them with Txn-Tokens


In the Terminology section, the Trust Domain value is being defined and referenced in the aud claim as universal resource identifier. It should be spelled Universal Resource Identifier and a reference to RFC3986 should be added. However, later in the document, the aud claim value is specified as defined in RFC7519. This RFC defines the aud claim as "StringOrURI". The different passages should be aligned. Furthermore, the examples for the aud claim values should be aligned accordingly. In section Txn-Token Request the POST request example to the token service uses: If an URI is used, I suggest to use 'https' instead of 'http'. Later the JWT body example of the Txn-Token just uses a string:


I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?


Changed MUST to MAY. Cardinality of the txn-token service is 0..1, not exactly one. MAY not be the appropriate framing, I'm open to alternative text here to describe this more correctly.
I've updated the PR with the language provided by NAME in two places where the previous language was found in the draft.


I'll create a new issue to track that logging concern
From Yaron's : : salted SHA256. : also, in most cases txn tokens MUST NOT be logged because they contain PII (e.g. a subject that's an email address).
I'm ok with these changes. I think we could give some more advise around logging that could be useful to the industry.


a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM


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.


To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good


An invalid link to the OpenID core spec has been fixed, as well as a section number referencing the draft.


OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.


for issue
URL Redirect URIs are not required to be registered if the client is using PAR and is a confidential client.
Discussed in the side meeting: Mike suggested that if 2.1 talks about this exception at all, it include a note that PAR defines an exception to the pre-registration requirement, which cites the PAR section. The text should be a heads-up to implementers - not appear to be defining something new.


Fixed URL
Thank you!
The following link appears to be broken. URL I have confirmed that the link works correctly by fixing `.


Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section


This small PR attempts to clarify an unfortunately not that rare mistake of server implementations where they respond with a JSON string and not the expected JSON number. In between the client implementations I maintain I get a PRs/issues at least twice a year which ask that the clients attempt to normalize the Token Endpoint response expires_in value instead of expecting it to be a number.
Just curious, won't this necessities adding the type for all other parameters? Because a few sentences after the proposed edit, the specification states:
It might. In the past this awkward definition in a follow up paragraph might've been seen as necessary because the same response parameters and their descriptions were used for the implicit grant response which does not have any data types associated given it's part of the url fragment. With that portion of the spec gone we might as well put the JSON data type in the descriptions for all token response parameters.


657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"


cb2616f30c91b68b99f8eb492cce400bf394bc08 - Removes a duplicate "are".


This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM


Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different


align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.


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._


RFC7230 references HTTP Messaging aka HTTP/1.1. OAuth2.1 is agnostic of the HTTP version instead. Consider that httpbis moves further definitions to including "user agent" and the and provides some details on validation


uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL


rewords a circular definition in §2.3
Some editorial improvements [x] definition of user agent ( is an abnf syntax)


consistently use "confidential or credentialed"
Some editorial improvements [x] definition of user agent ( is an abnf syntax)


From Vittorio: The “insufficientscope” description here is problematic. The privileges the AT carries/points to are not necessarily (or exclusively) represented by the included scopes (eg the RO might have granted document:read to the client, but RO might have no privileges for the particular document being requested in this particular call). It might be useful to specify that “invalidscope” should be used for authorization errors that can be actually expressed in terms of delegated authorization, leaving to RS implementers the freedom to handle other authorization issues (eg user privileges, RBAC, etc) with a different error code. Or at least, we should be clear that authorization logic not expressed via scopes is out of scope (pun not intended) for this specification. Note, this isn’t an abstract problem: there are SDKs out there that use “invalid_scope” for every permission issues. Very confusing.
to me, insufficientscope => the client does not have scope required for the request invalidscope => when I see invalid_scope, I think that the RS does not understand what scope the client has
I'll get clarity for what Vittorio is asking for.
Here is my restatement from thread with Vittorio: "insufficientscopes" - is the correct error to return if the application has not been granted the scopes required for the request Vittorio: "to me the highest order but is ensuring that the reader doesn’t abuse insufficientscopes and realizes other error codes are possible." I've submitted a pull request with suggested language changes


Thanks as lot Vittorio! You gave us a lot of homework but I think the draft will be improved a lot based on it. Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit (response type „idtoken“ or „code idtoken“) as there are examples in the wild where the idtoken is used as access token. Moreover, I‘m not aware of any systematic security threat analysis of those flows. I‘m fine with pointing out to readers that omission of response type „token“ does not deprecate other extension response types. WDYT? Thank you, I am so glad you think so! I hear you on the idtoken abuse. That would be easily solved by appending a “provided that the resulting idtoken is not abused by using it as access token”, in fact that would explicitly address one of the most common abuses we witness in this space by finally providing explicit language on the matter. I had frequent clashes with the Kubernetes crowd about it, and they required nuanced arguments, making them grok the concept of audience etc etc- all stuff that could have been avoided by having straightforward language along the lines of the above. We could argue whether that language belongs to the OIDC spec more than the OAuth2.1: my position is that we should take this opportunity to bring extra clarity, nothing prevents repeating that if the OIDC people will do their own updates in the future. I also hear you on the open endorsement, however I suspect that just saying what you suggest without mentioning OIDC at all will not solve the problem of people thinking this deprecates those OIDC flows, too. Perhaps a compromise would make it explicit that the security considerations that led to the omission of implicit for the token response type in oauth2.1 do not apply to those flows in OIDC, provided that the idtoken is not used as access token. So non an endorsement, but an explicit scoping statement would that sound more balanced?
Best place to add this is probably URL
We got consensus in the interim meeting to add the proposed text.


I think this is the tip of a larger iceberg, and I'd suggest we'd need to go deeper, if the IETF now thinks they may produce specs in this space. As I recall (others may add to the list), there are challenges to be considered by a proponent/IETF, which include: 1. Does the proposal rely on technologies specified by other Forums/SDOs? 2. Does the IETF have sufficient experience of the DC requirements and to review the proposals? 3. Does the proposal include experience of interoperability between different implementations? or a plan for this? 4. Does the DC traffic share resources with Internet traffic? 5. Specifically: does the method to be used between DCs or only within DCs? - How is this usage scoped? And what happens when the protocol is bridged across an Internet path? One or more of these has in the past thwarted progress towards adoption in the IETF, can we say something about this?
Do you want to take a shot at it? Do we need a completely different section about DC algorithms?
OK, it might be good to keep some version of this as a guidance for evaluating general-purpose protocols in datacenters, AND have a totally different section for DC-specific algorithms.
From IETF 119: Data centers with really small RTTs should be discussed as a special case
NAME We need to be specific about what we mean by datacenter (e.g. Hadoop queries), please give some details about the data center scenarios that we want to take into account NAME Typically you see proposals that rely on the fabric doing non-internet-y things, often there's combined implementation with the data plane, so we need to be specific there. Also saw some presentations this week about non-ethernet fabrics, need to describe what you see from your fabric and what you can then do from a congestion control perspective. NAME Some spillover from IPPM, doesn't work on public internet and not intended to. Number of things being deployed today, massive clusters, 100,000 endpoints constantly talking to each other. Special congestion controllers are very much needed. Trying to keep CPU/GPU non-idle all the time. We need something that is fast within 1-2 RTTs, doesn't matter if done on endpoints, NICs, switches.
There are sets of specific network characteristics; some of this relies on non-IETF specs and it would help to know the interop requirements between implementations and also what the coexistence requirements are for other flows.
Approving this text - LGTM, I propose to move the additional context on data centres to a separate issue, and resolve in a small separate PR against Section 2 & 3.


The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM


This is an attempt to address issue
Current version looks good to me as well, FWIW.
Thanks! Looks good to me, FWIW. :-)
I'm satisfied but won't merge until Gorry is satisfied too.This seems fine.


…ms..." AFAICT the goal is to consider harm induced relative to the harm induced by Reno/CUBIC. There may be other experimental algorithms that become "defined", which are not intended as a yardstick by which to measure harm.
cc: NAME NAME NAME NAME


Fixed an editorial problem resulting in removing the end of the sentence, which went on to say that you can't assume DSCP, etc. Also changed /many deployments/ to simply say this happens without saying it is often.
From NAME review: Section 3.2.2: Although there are clearly a number of network especially access networks that do deploy and use DSCP classes for its real-time media traffic I think this sentence is misleading. I would think that the majority of the WebRTC traffic carrying audio and video will in fact not be marked or have DSCP markings that survive into the general Internet. I would at least suggest to rewrite the above first sentence to indicate that although this may occur, the CC algorithm under consideration will have to deal with this type of traffic.


To address review comments and closing Issue
From NAME review: I reacted to the use of “forbidden” in this sentence. Would not “not intended at all for use in the Internet” be a better formulation? Because forbidden want me to invoke the Protocol Police if someone ever attempted to use it.
For me, this was meant to be stronger than "not intended", more like "confined to a limited to a controlled environment". RFC 8799 describes some of these cases, and could be a useful reference?
So I think a stronger wording is fine. But, an alternative formulation would be good that doesn't imply that you might get the protocol police after you.


Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"


Proposed text to add MP-TCP RFCs.
From NAME review: Section 5.8: What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification. I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities when managing different paths. Looking at the text I think we have scheduler application data, path availability checks as well as congestion control all impacting what is happening. What is truly congestion control here?


Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.


Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks


I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL


The title of section 5.2.1 mentions general-purpose transports but the content really about comparing against standard congestion control algorithms, I suggest to reflect that in the section title. URL
Hmmm: This was originally conceived as General-Purpose v Real-Time (next section). If we change this to "standard general-purpose congestion control algorithms" , does it then make "real-time look non-standard - so ought that now be "standard real-time congestion control algorithms"? Would that help?
It was not that clear that it was supposed to convey "general-purpose" VS "real-time". But my main point was that if this is all about congestion control for general purpose transport then lets say that. Competing with general purpose congestion control Competing with real-time congestion control


This paragraph is a good summery of what is available related to congestion control when it comes to real-time traffic in the context of this specification. However, all of those referenced resources were developed following the requirements set out by URL , also RFC8836 describes the aspects of real-time conversational media that helps the scope of being real-time. hence, I suggest we add a reference to RFC8836. URL


This responds to an AD question in review. The text is proposed to shed some light on how to go about evaluating a new CC algorithm, and when to use different approaches. It could be enough, or it could be improved, please think about how best to say this.
Thanks for this.. this looks like very good expression of the expectations on how one can think of evaluating the candidate congestion control algorithms without going into lengthy details. For the sake of clarity, it seems like the word "overload" (in the quoted sentence below) needs some explanation on what exactly we mean here - I am assuming we are referring to typical congestion scenarios on the path due to packet inflow and out flow mismatch in a bottleneck network node. >>"For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyse their stability and safety across a wide range of conditions, including overload".
overload, aka a lot more traffic than the path can handle... rather than typical congestion. Martin may have suggested wording...
While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter.
See below:On 27 May 2024, at 10:50, Zaheduzzaman Sarker NAME wrote: While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: NAME I am not sure how we add guidance … surely all of these method can be appropriate (more so for some of the evaluations) when bringing new work to the IETF. When last calling a draft - it would be good to see more than one approach where possible. Simulation ought to be better in understanding stability and identifying worst case impact; real lab or controlled tested could be good for understanding typical interactions with other traffic. I still wonder what we can best advise?Gorry Postscript: Reading again: my comment is about testing specific new CC mechanisms, if we're talking about a new CC algorithm (not just a new technique), then I agree with Martin below.
This is covered in Section 3, which is becoming Section 2: Is that good enough?
I have noticed that section. I think it is great that we are somewhat defining the criteria for a PS. But still we are not giving any hint on - say, if simulaiton results are good enough to be considered as experimental or shall we at least want to see some controlled testbed evaluations, or put it like this - what is considered as bare minimum empirical evidence? I would be great if we can put some clarity here.
I think we ought to expect some experiment results ... but how detailed, rather depends on what is being proposed. Having some experiments (even at large scale) and no simulation of theory (e.g. on how a method treats overload) would also seem very dangerous to me. These have always been the case in the past - i.e. TSVWG has pushed back to ICCRG to see experimental results AND some simulation/analysis when it comes to CC.
NAME are you saying we are just fine with some expection on evidence of experiments without specifying what is the minimum required environ to test in? we do have test cases defined for new algorithm testing, can't we at least say get inspiration or use them in the experiments?
Aha - I think you're suggesting we provide examples (rather than requirements) and we could refer to RFCs? If so, I'll try a PR.
I am not 100% sure this is necessary but given the AD review I'm happy to include it now.Just one little nit, but it looks good.


All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.


From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.


Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).


Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.


A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!


required -> REQUIRED
I agree with this change. The use of REQUIRED/RECOMMENDED for process rather than SHOULD/MUST for protocol, is not entirely consistent, but I think it is fine and unambiguous. Please do merge


Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)


at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.


The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.


This takes the initial part of that charter and adds to the introduction as a starting point for the new document.
Let's add text to the Introduction with our motivation and intention for revising RFC 5033, i.e., why and what do we want to update. The goal is to improve our alignment early on. This text could draw from the CCWG charter and prior discussions.


Update the QS text and various editorial suggestions. if merged.
I'll propose a PR with some editorial updates to the first part of the ID.