Hello Deb, I picked up a WIP PR from Brian to (hopefully) resolve your comments here <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/27>. I reverted brian's attempt to fix BCP 14 references as I think idnits v3 is in error after comparing how BCP14 is referenced here vs other recently published documents. But I'll happily take you up on your offer to align it with a different example, that being said, as many iterations of this I've tried they all came back as issues from idnits anyway.
S pozdravem, *Filip Skokan* On Thu, 26 Mar 2026 at 20:07, Brian Campbell <[email protected]> wrote: > Apologies, the meeting and travel and inability to access some systems > on-site definitely did disrupt the getting things done list for me. Further > disruption is coming for me with the kids' spring break starting soon (in a > few hours for all intents and purposes with respect to work). So I can only > apologize again as realistically an ETA for me responding in a useful way > isn't until the week after next. > > On Thu, Mar 26, 2026, 11:13 AM Deb Cooley <[email protected]> wrote: > >> Hi, >> >> Can I get an eta for responses to my comments? I had assumed there was >> some urgency, but I recognize the meeting tends to disrupt things for a >> minute or two. The good news is that we are probably only looking at a 2 >> week IETF Last Call. >> >> Deb >> >> On Wed, Mar 11, 2026 at 11:28 AM Deb Cooley <[email protected]> wrote: >> >>> Hi, >>> >>> Below is a complete set of my comments on this draft (I've pestered the >>> authors about a couple of early comments raised by idnits already). >>> >>> idnits v3 (experimental) raised three issues, one of them is legit, one >>> is borderline, and the last is clearly in error: >>> - idnits points out that it is preferred if BCP 14 is referenced. If >>> you need me to find you an example of how to do this, I can. >>> >>> - RFCs to be updated are not in the Abstract. >>> >>> - the third entry here is clearly in error. Mea Culpa. (about open.org >>> in the references) >>> >>> Section 1: (improve clarity) The token identifies the recipient? via >>> an audience value(s)? If that is correct, then maybe the second sentence >>> could be something like 'These tokens, which identify the recipient, >>> contain an audience value(s). s/aud/'aud' (or something to make it obvious >>> that this is a field name). >>> >>> Section 3, replacing text: I'm not sure the parenthetical for Section >>> 2.2 (The authors re not actually aware....)adds much. I would remove it. >>> >>> Section 4 a. and b.: Just to be sure I understand... for an >>> authorization grant the audience can be the token endpoint URL (and nothing >>> else), but for client authentication, the 'aud' claim value must not be the >>> token endpoint URL (it has to be the issuer identifier). Assuming that >>> audience = aud (audience) claim value. [I have no judgement on this, just >>> being sure this is what you intended to say.] >>> >>> Section 7.1.1, contact information: I believe we can use oauth for this >>> contact (vice a person). This is the authors' preference. >>> >>> >>> The publication window opens on Monday, hopefully it is fine to wait >>> until then. Once these are addressed, I will put the draft into IETF Last >>> Call (3 weeks because of IETF 125). >>> >>> Thanks for your patience, >>> Deb >>> >>> >>> >>> > *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.*
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
