[OAUTH-WG] Re: Roman Danyliw's Discuss on draft-ietf-oauth-status-list-15: (with DISCUSS and COMMENT)

[Brian Campbell <[e-mail]>]

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 <[e-mail]> wrote:

> inline w/ [DC]
>
> On Wed, Mar 25, 2026 at 3:45 PM Brian Campbell <[e-mail]>
> 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._