Thanks for kicking off the conversation! Inline:
On Fri, Sep 8, 2023 at 2: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? > > There are building blocks that "look like VC" but are actually vanilla JWT / relevant outside the 3 party model. I would recommend keeping them at OAuth (status list cwt is an example of this IMO). It's possible that a document at OAuth recognizing the data model elements of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents outside of OAuth to better defer to OAuth for "moving tokens, or leveraging successful protocols"... this could help reduce the data model reinvention everywhere else, and it could drive the common understanding of registered claim names to be interpreted consistently across JWT / CWT (and their SD friends). ** For whatever that work might be, how should the OAuth charter evolve to > support the work? > > I don't know, but I am happy to help : ) One thing that seems worth unpacking is why DCP at OIDF is leaving the OIDC part behind (paraphrasing, kristina probably has a better take): https://openid.net/wg/digital-credentials-protocols/ Are there things DCP might need from OAuth WG, how might the charter align to that 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? > I think so? but it depends on the comment above. Personally I would like to see the OAuth WG tackle this head on, especially because of the wallet / client / subject / holder confusion.... Starting with the people we are here to serve seems like a safe way to progress through the technical sugar (which I love). OS > > Thanks, > Roman, Hannes, and Rifaat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
