+1 to Brian’s and Orie’s observations. During last IETF, a question was asked whether draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of OAuth WG charter or not. A lot of comments observed that it is because as Brian has succinctly put it “a general JWT status/revocation mechanism (as defined in this draft) would fall easily within the remit of the WG as is”.
I also agree that it seems that focus has been unintentionally shifted away from working on this status list draft, which there is an interest and a need from the implementers to work on it. It would be great if we can discuss and agree whether this draft is in scope for oauth wg or not and if so whether we can start the call for adoption. Best, Kristina From: Orie Steele <orie@transmute.industries> Sent: Friday, September 29, 2023 10:35 AM To: Brian Campbell <bcampb...@pingidentity.com> Cc: Torsten Lodderstedt <tors...@lodderstedt.net>; torsten=40lodderstedt....@dmarc.ietf.org; Kristina Yasuda <kristina.yas...@microsoft.com>; oauth <oauth@ietf.org>; Paul Bastian <paul.bast...@bdr.de>; Christian Bormann <christiancarl.borm...@de.bosch.com> Subject: Re: [OAUTH-WG] OAuth and JWT/VC documents Inline: On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote: If I might offer an observation... The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*]) really just a generic status/revocation checking mechanism for JWTs in general. Given the history/lineage of JWT development within the OAuth WG, it seems like a general JWT status/revocation mechanism would fall easily within the remit of the WG as is. I agree with this. It seems to me as though the prospect of the formation of a new WG from the potential SPICE BoF that may or may not be a suitable future forum for the status list work has unintentionally delayed or diverted attention around consideration of the status list work being adopted and progressed in OAuth in the more near term. Speaking as a contributor to SPICE BoF, this was certainly never my intention. I don't think work should be delayed if it is well solved within an existing working group, and I agree that status lists are relevant to JWT and CWT generally, not just credentials. [*] it has some open TODOs for CWT based representations but no actual content as such, which could be removed to focus the scope of the draft. +1 On Tue, Sep 19, 2023 at 1:56 PM Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> wrote: Excellent. Inline: On Tue, Sep 19, 2023 at 2:12 PM <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote: Hi Orie, best regards, Torsten. Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>>: 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 ?) yes 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. We are open to move the credential work to a new working group. We are open to discuss whether that will be SPICE, so far it seems to be COSE centric. It’s clearly in everyone’s interest to have the JSON and COSE based credential formats aligned. I agree, I think a big part of this comes from trying to respect the work that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and OIDF. 3. Coordinate with CBOR based credential formats (wherever they may be) to ensure that architecture and conventions are as aligned as possible yes Happy to help however I can, regardless of where work items land. Let’s talk about how we can bring the COSE and JSON credential work together. Awesome, I think the most impactful way to achieve this would be adding a sentence like this to the SPICE BoF request, something to the effect of: The following documents would be transitioned from OAuth to SPICE if the WG forming BoF is successful. - draft-ietf-oauth-sd-jwt-vc - draft-looker-oauth-jwt-cwt-status-list It's debatable if the status list work item should move, since I see that as a generic token format that has applications beyond credentials. However, if authors feel it should be paired with `draft-ietf-oauth-sd-jwt-vc` I can also see that argument. Speaking as one of the authors of https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/ We would prefer to leverage a CWT status list format for that work, so if we consider the following work items as all possible candidates for SPICE: - draft-looker-oauth-jwt-cwt-status-list - draft-prorock-cose-sd-cwt - draft-ietf-oauth-sd-jwt-vc (perhaps we can adjust this to apply to both SD-JWT and SD-CWT). I can see us getting more concentrated contribution and having an easier time maintaining architectural alignment. I think sd-jwt should stay at OAuth, I agree with Brian, it's nearly complete, and I am happy to help close the gap on any remaining issues with the document. I'm happy to make further updates regarding consolidating credential work items in SPICE, and reducing the load on OAUTH WG, but I look to authors and the OAUTH working group to confirm if they are ok with the SPICE BoF request commenting on their work in this way. Perhaps we can discuss briefly in the OAuth office hours tomorrow. best regards, Torsten. Regards, OS On Mon, Sep 18, 2023 at 7:06 AM <torsten=40lodderstedt....@dmarc.ietf.org<https://mailto: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<https://mailto: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://mailto:OAuth@ietf.org/>https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<https://mailto:OAuth@ietf.org/>https://www.ietf.org/mailman/listinfo/oauth -- ORIE STEELEChief Technology Officerwww.transmute.industries[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>_______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/> [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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. -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/> [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
