Torsten, Thanks for sharing this excellent framing.
I agree with everything you said. Please correct me if I'm wrong about anything in this summary: 1. Keep working on JWT based credential formats at OAuth (implicit, don't expand OAuth charter to work on CWT credential formats ?) 2. If a new working group (SPICE) is formed focused on credentials, authors are open moving credential specific work items there, and don't plan new credential related items at OAuth. 3. Coordinate with CBOR based credential formats (wherever they may be) to ensure that architecture and conventions are as aligned as possible Happy to help however I can, regardless of where work items land. Regards, OS On Mon, Sep 18, 2023 at 7:06 AM <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > Hi Roman, > > I’m writing this post on behalf of the group of co-authors who proposed > the following drafts for adoption by the OAuth WG: > > draft-ietf-oauth-attestation-based-client-auth > draft-ietf-oauth-sd-jwt-vc > draft-looker-oauth-jwt-cwt-status-list > > We have brought these drafts to the IETF because they are built on IETF > drafts/standards and enhance them. Those drafts are interrelated and part > of a bigger effort to provide initiatives around the globe for building > ecosystems based on the Issuer/Holder/Verifier model, especially focussing > on EU’s eIDAS, with interoperable technical standards. > > The work is based on two pillars, Selective Disclosure JWT (SD-JWT) and > OpenID for Verifiable Credentials (OID4VC). The latter is a credential > format agnostic family of protocols for issuing and presenting verifiable > credentials and authenticating users based on keys in the wallet. These > specifications are being standardized at the OpenID Foundation; they are > already referenced by the eIDAS Architecture and Reference Framework. > > SD-JWT and OID4VC are combined in a specification designated as “OpenID > for Verifiable Credentials High Assurance Interoperability Profile with > SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the credential format > SD-JWT VC to allow implementers to build truly interoperable systems. This > is the contribution we intend to make to eIDAS. > > While working on HAIP we identified missing pieces in the overall picture, > most notably a way to use well-established JWT content rules and its > extensibility model as basis for representing Verifiable Credentials with > JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc. > > We also noticed Verifiable Credentials are typically long living > credentials and thus need a way for its issuer to influence its status. > That’s why we drafted draft-looker-oauth-jwt-cwt-status-list and > incorporated it into draft-ietf-oauth-sd-jwt-vc. > > In addition, we learned while working with the eIDAS expert group and > others that wallet to issuer authentication needs to fulfill very special > requirements. That’s why we drafted > draft-ietf-oauth-attestation-based-client-auth as a new client > authentication method. > > To sum up, draft-ietf-oauth-sd-jwt-vc and > draft-looker-oauth-jwt-cwt-status-list extend the work being done around > SD-JWT so we feel the OAuth WG is the best place to evolved them. However, > we are open to discuss to carve out the work around credential formats and > supporting mechanisms into a new working group. > > draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so > we believe it belongs to the OAuth WG. > > ** 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? > > draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list are > fundamental building blocks on the level of credential formats for building > applications according to the Issuer/Holder/Verifier model. A lot of > initiatives around the globe are looking for technical standards for this > kind of application now. (For example, the eIDAS expert group hopes to > finalize its Architectural Reference Framework (ARF) this year.) So there > is a window of opportunity for IETF and this group to make an impact with > solid, secure and usable technical standards. > > We don’t plan further contributions in this space to the WG beyond the > proposed drafts. > > ** What unknown about the direction and needed tasks? > > I hope I could shed some light on our plans. > > ** For whatever that work might be, how should the OAuth charter evolve to > support the work? > > We suggest extending the charter to cover work on credential formats and > related mechanisms based on JWTs. As already mentioned above, we are also > open to moving this work into a new dedicated working group once such a > working group is operational. That working group might be established as a > result of the SPICE effort. It would be good to coordinate closely with > those developing CBOR-based credentials to keep that work and ours > architecturally aligned. We, however, see the need to keep working on the > drafts to meet the expectations of current and prospect implementers. > > ** 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? > > We suggest clearly distinguishing protocol aspects from data format > aspects. draft-ietf-oauth-selective-disclosure-jwt as part of the > credential format aspect has dependencies on JWT but no dependencies on RFC > 6749. > > There is work to be done to cater for protocols sitting on top of OAuth > for supporting the issuer/holder/verifier model. OpenID4VC is built on top > of OAuth and we have come up with some observations around that. For > example, clients (either verifiers or wallets acting as clients towards > issuers) are typically not managed by the AS. Either there is a 3rd party > that the AS relies on for that purpose, or the client starts interacting > without any pre-established relationship. Also, in a wallet world, we see > the need to allow an app on the phone to securely authenticate towards an > AS, which requires key bound assertions. > draft-ietf-oauth-attestation-based-client-auth is our proposal to cope with > those issues. > > best regards, > Torsten. > Am 8. Sept. 2023, 21:07 +0200 schrieb Roman Danyliw <r...@cert.org>: > > 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 > > _______________________________________________ > 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
