Ciao Rifaat I can say in the vest of an implementer, that VC documents are like unrequited love, you know you need it but it's not something you can build on.
Here I represent many organizations that are working to build on these, with deadlines. I express my strong support for these brand new specs, since I Need them and I share the vision behind them. All about how these can became reality would be search and found in a OAuth WG that would show how this would be then possible. I support the adoption and I'm implementing the so called vcstuff drafts Il ven 29 set 2023, 20:16 Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> ha scritto: > There are two reasons for not calling for the adoption of this document: > 1. The SPICE discussion, which gave the impression that the plan is to > migrate this to a new dedicated WG. > 2. Some people questioned whether this is in scope or not. > > If the first one is not an issue, and there is no plan to migrate this to > a different WG, then we can definitely start a call for adoption and see > what happens. > > Regards, > Rifaat > > > On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda <Kristina.Yasuda= > 40microsoft....@dmarc.ietf.org> wrote: > >> +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> 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> >> wrote: >> >> Excellent. >> >> Inline: >> >> >> >> On Tue, Sep 19, 2023 at 2:12 PM <tors...@lodderstedt.net> wrote: >> >> Hi Orie, >> >> >> >> best regards, >> >> Torsten. >> >> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele < >> 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 STEELE*Chief Technology Officerwww.transmute.industries >> <https://transmute.industries/> >> _______________________________________________ >> 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 >> >> >> *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 >> >> <https://transmute.industries/> >> _______________________________________________ >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
