> > Send me the mail archive link when you make the media type registration > request. I will need to add it to the ballot before the telechat. >
https://mailarchive.ietf.org/arch/msg/media-types/WR74LiJR7hW2PVwZI0x74HCxAR4/ Note: This request was made before the contact change published in -07 S pozdravem, *Filip Skokan* On Fri, 27 Mar 2026 at 13:30, Deb Cooley <[email protected]> wrote: > One more thing (apologies). > > Send me the mail archive link when you make the media type registration > request. I will need to add it to the ballot before the telechat. > > Deb > > On Fri, Mar 27, 2026 at 8:27 AM Deb Cooley <[email protected]> wrote: > >> Thank you very much. I will send it to IETF Last Call. >> >> I'm assuming that my read of Section 4a and b. was correct...If it >> wasn't, please send me a message setting me straight. >> >> Deb >> >> On Thu, Mar 26, 2026 at 7:51 PM Michael Jones < >> [email protected]> wrote: >> >>> https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-07.html has >>> been published to address your comments, Deb. >>> >>> Thanks, >>> -- Mike >>> >>> -----Original Message----- >>> From: Michael Jones <[email protected]> >>> Sent: Thursday, March 26, 2026 3:36 PM >>> To: Deb Cooley <[email protected]>; Filip Skokan <[email protected]> >>> Cc: Brian Campbell <[email protected]>; >>> [email protected]; Web Authorization >>> Protocol Working Group <[email protected]>; oauth <[email protected]> >>> Subject: RE: AD comments on draft-ietf-oauth-rfc7523bis >>> >>> I approved the PR >>> https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/27. >>> Thanks for doing that, guys. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Deb Cooley <[email protected]> >>> Sent: Thursday, March 26, 2026 3:27 PM >>> To: Filip Skokan <[email protected]> >>> Cc: Brian Campbell <[email protected]>; >>> [email protected]; Web Authorization >>> Protocol Working Group <[email protected]>; oauth <[email protected]> >>> Subject: Re: AD comments on draft-ietf-oauth-rfc7523bis >>> >>> Filip (and Brian), >>> >>> You are right, I have also come to the conclusion that idnits is wrong >>> here. apologies for that. >>> >>> I will look at the PR soonest (prolly tomorrow). Although waiting until >>> after spring breaks are over (I forgot about those, again apologies), >>> that is fine as well. >>> >>> Deb >>> >>> On Thu, Mar 26, 2026 at 4:09 PM Filip Skokan <[email protected]> wrote: >>> >>> > Hello Deb, >>> > >>> > I picked up a WIP PR from Brian to (hopefully) resolve your comments >>> > here >>> > <https://gith/ >>> > %2F&data=05%7C02%7C%7C83e6fef89cb448fd867e08de8b880ab1%7C84df9e7fe9f64 >>> > 0afb435aaaaaaaaaaaa%7C1%7C0%7C639101613575943450%7CUnknown%7CTWFpbGZsb >>> > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mh1gEWVXYZfEIPMMaHvRgVe0Y >>> > nZGCEZBbcZCqdojSTw%3D&reserved=0 >>> > ub.com%2Foauth-wg%2Fdraft-ietf-oauth-rfc7523bis%2Fpull%2F27&data=05%7C >>> > 02%7C%7Caeb3cee0ed444f527dc108de8b86dc41%7C84df9e7fe9f640afb435aaaaaaa >>> > aaaaa%7C1%7C0%7C639101608487502793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 >>> > >>> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=52LLsQQE6Bzv44HFNxNvkCK0%2BaWjdKcWFFXyUBGia%2BY%3D&reserved=0>. >>> 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 >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
