Hi all, Is there perhaps precedent in IETF specifications to have a non-normative "Explainer" type document or section in a document which just says "Here's what implementers might/should want to do, but this isn't a normative part of the specification"?
— Emelia > On 25 Mar 2026, at 23:12, Deb Cooley <[email protected]> wrote: > > inline w/ [DC] > > On Wed, Mar 25, 2026 at 3:45 PM Brian Campbell <[email protected] > <mailto:[email protected]>> wrote: >> >> >> On Tue, Mar 24, 2026 at 4:01 PM Deb Cooley <[email protected] >> <mailto:[email protected]>> wrote: >>> I don't really like hats, but regardless, I'm wearing my AD hat.... >> >> I don't often wear hats either but I happen to be wearing my Denver East >> High School hat in support of the Angels competing in the pool later >> today... >> >> <hat.jpg> >> >> > [DC] I hope your swimmers are fast fishies. I'll be forever jealous > (especially of beautiful butterfly). >> >>> >>> I beg to differ. >> >> Reasonable people can disagree. Unreasonable people can disagree too. >> Hopefully we're in the territory of the former here but one can never be >> sure. > > [DC] most definitely the former, I'm just grumpy - fake jetlag mostly. > Apologies, I try to not be grumpy most days. >> >>> >>> Assuming you mean this item (the first in Roman's discuss): >>> ** For the OAUTH WG Chairs and responsible AD: this document appears to be >>> describing new mechanisms for CWT and ISO mdoc; and a new sub-registry for >>> CWT. >>> I could use help understanding how this fits into the defined scope in >>> OAUTH >>> WG charter given that the status-list work isn’t explicitly named and CWT >>> and >>> mdoc aren’t directly tied to “increasing interoperability of OAuth >>> deployments >>> and to improve security [in OAuth deployments].” >> >> Yes, that's the one. I referred to the "first DISCUSS point raised" in this >> thread with the subject, "Roman Danyliw's Discuss on [...]" which I thought >> was reasonably clear. But two of the draft authors asked out-of-band for >> clarification so it seems it wasn't clear. > > [DC] huh.... I thought it was clear, but I wanted to be sure. >> >> I took that item in the discuss position to be Roman questioning how new >> CBOR/COSE/CWT mechanisms and establishing a new CWT sub-registry fit the >> OAUTH WG charter. I think we agree that it does not. And that even after a >> prospective recharter, it still won't. > > [DC] As stated, this is true. OAUTH will not be doing a land grab of either > ace or spice chartered work. > >> >> Perhaps understanding that is sufficient for Roman to clear the discuss. >> But, in the spirit of having a discussion, I wanted to be make it >> unambiguous (though apparently I didn't do a good job) that the >> CBOR/COSE/CWT bits are not currently in the charter, nor will they be in a >> prospective future charter. >> >>> >>> Both spice and ace were contacted on their mailing lists asking for their >>> concurrence (i.e. putting this together into one specification vice >>> splintering the information into 2 specifications). Those are the mailing >>> list links in my message. >> >> I don't think getting permission (or really lack of objection) from >> different WGs is at all equivalent to being in the charter. But maybe this >> is another point on which reasonable people can disagree. > > [DC] my point here is: if there must be a status list draft, I'd rather see > one which includes everything, vice multiple drafts, one for each technology. > If there is one place for a developer/integrator to go for information on > how to do these status lists, that's better, no? Because once the draft is > an RFC, the people implementing it won't have to care which working group it > came from. They will have one and only one place to look. > >> >>> >>> As for the mdoc in ISO, that was modified to be merely an example, i.e. >>> non-normative. >>> >>> Of course, I'm assuming that you brought all this up while the draft was in >>> the working group, right? >> >> Yes. Actually even before it was in the working group, when, as mentioned >> and linked in a prior message here, I advocated for this draft's adoption in >> the WG with a scope appropriate to the WG. >> >> >>> Because after it is passed to me, seems.... um... late.... >>> >>> What am I missing? >>> >>> Deb >>> >>> p.s. Note: you should really want an oauth recharter to ensure that the >>> SD-JWT VC draft is squarely in charter, no? >> >> That feels a little bit like the old trope of the mobster saying, "that's a >> nice little draft you got there, it'd be a shame if something happened to >> it..." >> >> I acknowledge that work and RFC9901 are on the margins of the chartered >> scope. That's also mentioned and linked in a prior message in this thread. I >> also believe it is more defensible with respect to the current charter and >> precedent than CBOR/COSE/CWT stuff. > > [DC] yeah, I will just lean on the 'I'm grumpy' card here. No one has ever > said I was a mobster before. Brutally honest, yes, Mean, sometimes, Mobster, > no.... huh.... could be a new low. I do apologize for the veiled threat. >> >> >>> >>> >>> On Mon, Mar 23, 2026 at 12:23 PM Brian Campbell <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Significant parts of this draft fall well outside the defined scope of the >>>> OAUTH WG charter and, while the responsible AD and the OAUTH chairs plan >>>> to start work on a recharter, those parts of the draft will still not be >>>> in the scope of that prospective new charter. >>>> >>>> It seems the impetus behind the first DISCUSS point raised have not been >>>> addressed. >>>> >>>> On Fri, Mar 20, 2026 at 8:05 AM Deb Cooley <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> This message is to pop this to the top of your queue. The authors have >>>>> addressed your comments as is reflected in the current draft version (and >>>>> messages to yourself on 7 and 15 Jan). Both ace and spice [1] were >>>>> queried with positive feedback. >>>>> >>>>> The action we are seeking is to clear the discuss. >>>>> >>>>> In addition to this, the oauth chairs and I will work on a recharter, as >>>>> soon as they have recovered from IETF 125 travel. >>>>> >>>>> [0] >>>>> https://mailarchive.ietf.org/arch/msg/ace/vmRRPwPRHXkAhP-MfpKgd0pH2Ns/ >>>>> [1] >>>>> https://mailarchive.ietf.org/arch/msg/spice/SMgovRcQ3LicZG2YXlTlA_BYGj8/ >>>>> >>>>> Deb >>>>> >>>>> On Tue, Feb 3, 2026 at 3:57 PM Brian Campbell <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> A "normal" implementer (not seeped in IETF lore and knowledge) likely >>>>>> won't know or care about the differences in WG of origin or respective >>>>>> charter. But they will likely notice that the scope and content of the >>>>>> document, which presumably should have been guided and constrained by >>>>>> the charter, is incongruent with expectations and related work. >>>>>> >>>>>> On Sun, Jan 18, 2026 at 4:52 AM Deb Cooley <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>>> inline w/ [DC] >>>>>>> >>>>>>> On Fri, Jan 16, 2026 at 6:11 PM Brian Campbell >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 6, 2026 at 3:29 PM Roman Danyliw via Datatracker >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>> Roman Danyliw has entered the following ballot position ... >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> DISCUSS: >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> ** For the OAUTH WG Chairs and responsible AD: this document appears >>>>>>>>> to be >>>>>>>>> describing new mechanisms for CWT and ISO mdoc; and a new >>>>>>>>> sub-registry for CWT. >>>>>>>>> I could use help understanding how this fits into the defined scope >>>>>>>>> in OAUTH >>>>>>>>> WG charter given that the status-list work isn’t explicitly named and >>>>>>>>> CWT and >>>>>>>>> mdoc aren’t directly tied to “increasing interoperability of OAuth >>>>>>>>> deployments >>>>>>>>> and to improve security [in OAuth deployments].” >>>>>>>> >>>>>>>> I am but an individual OAuth Working Group participant, albeit one who >>>>>>>> has spent some time operating around - occasionally pushing at >>>>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/6qjAsqLwyp5WoxqY3dVv8SJ5nVM/> >>>>>>>> - the margins of the chartered scope. Before the document was >>>>>>>> adopted, and even before SPICE formed a working group, I argued for a >>>>>>>> narrower scope for the draft (certainly without a CTW variant >>>>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/Gekd-vzNy4rC3HsIl1FDi6nWuuI/>, >>>>>>>> and arguably without any signed representation at all >>>>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/bO9FXfCvvIsxNz-0cnEnpDDh8mE/>). >>>>>>>> Those suggestions went unheeded, but I don’t think that “things just >>>>>>>> happened that way” meaningfully addresses your question. >>>>>>>> >>>>>>>> The inclusion of CBOR/COSE/CWT encodings, ostensibly to better support >>>>>>>> the likely technology stack in ISO mdoc implementations, which is more >>>>>>>> or less how it has been explained to me, does seem to fall well >>>>>>>> outside the chartered scope. More recently, I’ve heard it suggested >>>>>>>> that the work is already done and the content in the document, so it’s >>>>>>>> better to simply leave it. That argument does resonate to some extent. >>>>>>>> Still, I do wonder whether doing so would set an unfortunate precedent >>>>>>>> that straying well beyond the charter is tacitly endorsed. >>>>>>>> >>>>>>> [DC] To be crystal clear, the plan is to take two actions: >>>>>>> 1. Consult with both ace and spice to get agreement to put these >>>>>>> specifications all in one place (a one stop shop, as it were), vice >>>>>>> publishing them in multiple places based on the charters of the working >>>>>>> groups. Multiple specifications will likely not be completely 'matchy >>>>>>> matchy' as I say, possibly with small changes, complicating >>>>>>> implementations. As a note, I will point out that once the RFC is >>>>>>> issued, the normal implementer (not seeped in IETF lore and knowledge) >>>>>>> won't know the difference. >>>>>>> >>>>>>> 2. Both the AD (me) and the oauth chairs will begin work on a >>>>>>> recharter of oauth, it was last rechartered in 2016, so it is dated in >>>>>>> the best case. This recharter will not bring this particular draft >>>>>>> into charter (as CWT is clearly being worked in other working groups). >>>>>>> So, while that recharter is past due, it is orthogonal to this >>>>>>> particular specification. >>>>>>> >>>>>>> My question is this: Can the discuss be cleared with agreement from >>>>>>> the wgs in question (#1 above). >>>>>>> >> >> >> >> >> >> 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]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
