Thanks Steffen! Hi Markus,
We understand the frustration, but we think this is the best way forward for all parties involved. Regards, Rifaat On Tue, Sep 16, 2025 at 5:57 AM Steffen Schwalm <[email protected]> wrote: > Hi Markus, > > > > while I understand you anger: As long as extension are there you could add > an additional spec describing how to use DID within SD-JWT VC. As we > already have possible SDO for this I kindly ask you to contribute on the > subject. > > > > @Rifaat, @Hannes: Thanks for your work as chairs. > > > > Best > > Steffen > > > > *Von:* Markus Sabadello <[email protected]> > *Gesendet:* Montag, 15. September 2025 19:58 > *An:* [email protected] > *Betreff:* [OAUTH-WG] Re: Call for WG Feedback on DID Resolution in > SD-JWT VC > > > > *Caution:* This email originated from outside of the organization. > Despite an upstream security check of attachments and links by Microsoft > Defender for Office, a residual risk always remains. Only open attachments > and links from known and trusted senders. > > On one of the relevant Github threads, 15 people agreed that removal was a > bad idea: > > https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/250#issuecomment-2256016913 > > There are many other Github issues, comments, and PRs that also expressed > disagreement with the removal. > > Several people have stated on Github that removal would be a problem for > their existing implementations. > > In the previous attempt to remove DIDs, that removal had to be reverted > after intervention by the chairs. > > In this last PR which now removed DIDs, there were more -1 than +1 votes > on Github. > > In an earlier version of the specification, support for DID Resolution was > mandatory; after much discussion, the WG consensus was to make it optional. > > In the various discussions about this topic, multiple substantial > arguments were articulated why the feature shouldn't be removed. None of > those arguments were discussed in the WG. > > In contrast, no real arguments have been brought forth why this > (optional!) feature should be removed; instead, the arguments in favor of > removal were "it's tiresome", "it's stuff that doesn't work anyway", "it's > a reputational risk", "there were no real objections to removal other than > DIDs are great", "you can define an extension", and "DIDs are not > interoperable" (without really explaining or discussing this last claim). > > The editor who has now removed the feature in his fifth attempt has in the > past admitted to trying to prevent active WG discussion about this topic. > > At the last IETF meeting, that same editor has given an extremely > one-sided presentation about this controversial topic, with almost no time > allowed for alternative arguments and discussion. > > At least one of the people who are now supporting removal in this thread > is supporting it "because there is no chance to win". > > Silently removing a feature that many people didn't want to be removed, > and then asking for agreement to the removal afterwards, is not an > appropriate approach to handling such a situation. > > The discussion culture around removal of this feature has been passive > aggressive, provocative, dismissive, instead of substantial discussion > about the pros and cons. The group pressure to remove this has been > enormous. > > Markus > > On 9/13/25 1:53 AM, Rifaat Shekh-Yusef wrote: > > All, > > > > This is an official call for getting the WG’s opinion on the last open > issue in draft-ietf-oauth-sd-jwt-vc-10 concerning the *removal* of the *DID > Document Resolution*. > > In an early version of the SD-JWT VC document, we had three Issuer-signed > JWT Verification Key Validation techniques: > > 1. JWT VC Issuer Metadata > 2. X509 based certificates > 3. DID Document Resolution > > > Do you agree with the removal of the DID Document Resolution option from > the SD JWT VC specification? > > Please note that this *does not *prevent future *extensions*. Interested > parties are free to define and publish an extension that adds DID Document > Resolution support, if desired. > > Please, reply on the *mailing list *with your preference by *October 3rd*. > > > > Regards, > > Rifaat & Hannes > > > > _______________________________________________ > > OAuth mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
