I agree with Brian's comments. It's clear to me that SD-JWT has benefited a lot from the expertise of the OAuth WG.
OS On Fri, Sep 15, 2023, 4:12 PM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > Hi Roman, > > I'm going to dodge some of the bigger picture questions but wanted to give > a bit of historical context/justification for the > draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG. > > JWT <https://datatracker.ietf.org/doc/rfc7519/> itself was a product of > OAuth WG yet was intentionally developed as a general-purpose token format > with no direct dependency or relation to RFC6749 > <https://datatracker.ietf.org/doc/html/rfc6749>. JWT certainly had useful > applications in OAuth/RFC6749 but it wasn't limited to such. JWT has seen > widespread usage in a variety of applications and other standards, which is > arguably a testament to the intent and nature of that development. > > SD-JWT > <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/> > is basically just a selective disclosure mechanism for JWT. It builds on > and leverages the established and familiar constructs of JWT. It is > similarly intended to be a general-purpose specification. Given that broad > intent and SD-JWT's relationship to JWT, with JWT's heritage of being > developed in the OAuth WG, it seemed only natural and appropriate that > SD-JWT follow suit and find its "home" for development in the OAuth WG too. > SD-JWT has been an active work item of the WG for about a year and has > matured nicely in that environment. I'm (maybe naively) hoping that the > work is closer to the end of its time in WG than it is to the beginning. > > > > > On Fri, Sep 8, 2023 at 1:08 PM Roman Danyliw <r...@cert.org> wrote: > >> Hi! >> >> We've observed growing energy around JWT, selective disclosure and VC >> related topics in the WG in recent meetings. We spent almost all of the >> third OAuth meeting at IETF 117 on related topics. The initial SD-JWT >> (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with >> SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). There is also work like >> draft-looker-oauth-jwt-cwt-status-list being proposed. >> >> As promised at IETF 117, we would like to start a conversation about the >> direction the WG would like to take at a strategic level rather than >> continuing to deal this topic in one document increments of additional >> scope. >> >> ** What's the body of work around SD/JWT/VC that should be done and how >> much work will that be? What needs to be done first? What unknown about >> the direction and needed tasks? >> >> ** For whatever that work might be, how should the OAuth charter evolve >> to support the work? >> >> ** Is there work to be done around bridging the architectural narrative >> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model >> (issuer, holder, verifier) used in >> draft-ietf-oauth-selective-disclosure-jwt? >> >> Thanks, >> Roman, Hannes, and Rifaat >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
