Apologies for the untimeliness of the reply here, life (mostly spring break in this case) gets in the way sometimes. More inline w/ [BC] and some parts snipped, which may or may not make this readable...
On Wed, Mar 25, 2026 at 4:12 PM Deb Cooley <[email protected]> wrote: > inline w/ [DC] > > On Wed, Mar 25, 2026 at 3:45 PM Brian Campbell <[email protected]> > wrote: > >> >> >>> 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. > [BC] I'm grumpy too and was definitely also including myself in that uncertainty of possibly being unreasonable. I'd like to blame real jetlag for the grumpiness but in this case I think it mostly stems from feeling like I provided very reasonable and grounded feedback/advice on this draft early on. And did so in service of helping the draft find an appropriate WG and progress. At a point in time when progress was very much uncertain. Then had that feedback/advice go unheeded. Only to see the IETF Chair raise basically the same point of concern in the final balloting as part of a blocking DISCUSS. It's frustrating and grumpiness inducing (more than the usual grumpiness even). Is it frustrating that things are held up at this stage? And further frustrating to have a mere WG participant chime in about it? I'm sure it is. It's also frustrating, from the perspective of that mere WG participant, that the situation was entirely avoidable. >>> 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. > [BC] Colloquially, I'm really hoping this will come to be known as Cooley's 'Matchy Matchy' Corollary. And I do follow the line of reasoning. But there are other ways to slice it too. I'd posit that a charter (even while acknowledging they sometimes get neglected) serves multiple functions. One function is about carving up territory and bringing the right competence to bear on the work. I think that's what your point here addresses. But another function is focusing the output to be reasonably cohesive. Having two completely different serialization and securing mechanisms in one document is a major disservice to consumers of that document who don't need both. It significantly adds to the length and cognitive overhead of the draft and can also create a synthetic expectation that implementing it all is somehow necessary. To the best of my knowledge, neither SPICE nor ACE is using this work or has expressed any interest in it. The justification, as I understand it, for the CBOR/COSE/CWT parts is so that prospective mdoc/mdl implementations could consume status lists with the same technology stack they already have. That's clearly outside the OAUTH WG charter (current and future) and arguably outside even a reasonable conception of IETF's consensus. Is it worth the charter scope shenanigans and the significantly expanded scope and complexity of the document? I do think reasonable people can disagree there but my opinion is obviously that it is not worth it. > >> >> >>> >>> 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. > To be fair, "feels a little bit like the old trope of the mobster" is not the same as mobster. But I'll apologize too for the veiled accusation. -- _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]
