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

["Emelia S." <[e-mail]>]

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