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]
