inline w/ [DC] On Wed, Mar 25, 2026 at 3:45 PM Brian Campbell <[email protected]> wrote:
> > > On Tue, Mar 24, 2026 at 4:01 PM Deb Cooley <[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... > > [image: 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]> 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]> 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]> 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]> >>>>> wrote: >>>>> >>>>>> inline w/ [DC] >>>>>> >>>>>> On Fri, Jan 16, 2026 at 6:11 PM Brian Campbell <bcampbell= >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 6, 2026 at 3:29 PM Roman Danyliw via Datatracker < >>>>>>> [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]
