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
