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] > 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. > 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. 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. 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. > > 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. > > > 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]
