Thanks Giuseppe! Please, reply to the *official* call for adoption email.
Regards, Rifaat On Fri, Sep 29, 2023 at 6:26 PM Giuseppe De Marco <demarco...@gmail.com> wrote: > 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
