I don't really like hats, but regardless, I'm wearing my AD hat.... I beg to differ.
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].” 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. 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? 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? 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.* >>>> >>>> >>> *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] >> > > *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]
