Hi Steffen, Thank you for your interest in this work. You've made some strong statements, particularly regarding IETF procedures and norms—especially for what appears to be your second ever <https://mailarchive.ietf.org/arch/search/?as=1&email_list=&end_date=2024-11-14&q=text%3A%28Schwalm%29&qdr=c&start_date=1234-11-10> contribution to an IETF mailing list. It seems there may be some misunderstandings or perhaps something lost in translation. With that in mind, I’ve made an effort to clarify a few points inline below (though this is not an exhaustive list).
On Wed, Nov 13, 2024 at 2:34 PM Steffen Schwalm <Steffen.Schwalm@msg.group> wrote: > Hi Daniel, > > > > great work! Looking at [1] and [2] there`s obviously no consensus > Gauging working group consensus, even rough consensus, is not an easy task. Despite the accusations levied here, the document editors take that task very seriously. It is necessarily subjective. And involves considerably more than github. > – which implies a breach of Sections 1.2, 5 and 9.2 of the IETF Directives > on Internet Standards Process. > Assuming you mean RFC 2026, which has a similar but distinctly different title. It's a bit unusual to imply a breach of RFC 2026 like that. Section 1.2 is part of the introduction and seems like an awkward thing to breach. Section 5 is about the Best Current Practice RFC subseries, which isn't even remotely applicable to anything at question here. Section 9.2 is about exclusions from the variance procedure and seems similarly unrelated to the topic at hand. > An assumption is great but not sufficient as in any standardization body. > According to IETF rules the consensus shall be ensured before announcement > of new version. > That is entirely incorrect. Drafts are an integral part of the IETF consensus process. > The profiling you suggest is technically the worst solution as it leads > directly to additional effort to ensure interoperability between > fundamental standard and its profiles and extend complexity unnecessarily. > That is an opinion offered as fact. And a rather tenuous opinion at that. In my opinion anyway. > Means the inclusion of DID in SD-JWT-VC shall be discussed with the > relevant experts such as Markus Sabadello, Alen Horvat etc. Decision making > based on actual consensus not assumed one. > I am not entirely sure what that means, to be honest. But I am reasonably sure it's not based on anything real. I'd suggest that the relevant experts and DID proponents write a draft <https://authors.ietf.org/en/home> that describes DID usage with SD-JWT VC (or base SD-JWT or even at the general JWT/JOSE layer) with language that's sufficient for interoperability. That work could then be brought forward for consideration as part of the consensus-building process. > > > Formal appeal acc. Section 6.5 of IETF Directives on Internet Standards > Process will follow in case the IETF directives will still be ignored. > I am unable to find a document titled "IETF Directives on Internet Standards Process" so I'll again assume you mean RFC 2026 here. In my reading of Section 6.5 of RFC 2026 The Internet Standards Process -- Revision 3, the appeal process isn't really intended for challenging discrete revisions of a WG draft. While your threat has been noted, and I assure you that it has been noted, before pursuing it, you might first want to carefully consider the applicability of such action to the matter at hand and the impact on the time and energy of those required to evaluate it. I can't speak for IETF leadership (WG chairs, ADs/IESG, IAB, etc.), of course, but I know that I don't typically appreciate having my time wasted by what appear to be frivolous misunderstandings. > > > Best > Steffen > > > > *Von:* Daniel Fett <mail=40danielfett...@dmarc.ietf.org> > *Gesendet:* Mittwoch, 13. November 2024 21:03 > *An:* oauth@ietf.org > *Betreff:* [OAUTH-WG] Re: I-D Action: draft-ietf-oauth-sd-jwt-vc-06.txt > > > > *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. > > Hi all, > > we are happy to announce version -06 of SD-JWT VC. In this release, we're > updating the media type from application/vc+sd-jwt to application/dc+sd-jwt > (for background, see Brian's excellent summary at the IETF meeting last > week [0]). > > This version also removes references to DIDs in the specification, while > leaving the door open for those who want to define a profile of SD-JWT VC > using DIDs. The previously provided text on DIDs was underspecified and > therefore not helpful, and a more complete specification would exceed the > scope of this document while interoperability issues would remain. We think > that those ecosystems wanting to use DIDs are best served by defining a > profile for doing so. > > We would like to point out that there are concerns about this step raised > both in the respective issue [1] and in the pull request [2]. While it is > our understanding from various discussions that there is a consensus for > the removal of the references to DIDs in the group, this change had not > been discussed here on the mailing list before. So we'd like to take this > opportunity to do that now. > > As a minor point, this version adds the “Status” field for the well-known > URI registration per IANA early review. > > -Daniel > > > > [0] https://www.youtube.com/watch?v=LvIBqlHkuXY > > [1] https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/250 > > [2] https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/251 > > Am 13.11.24 um 21:45 schrieb internet-dra...@ietf.org: > > Internet-Draft draft-ietf-oauth-sd-jwt-vc-06.txt is now available. It is a > > work item of the Web Authorization Protocol (OAUTH) WG of the IETF. > > > > Title: SD-JWT-based Verifiable Credentials (SD-JWT VC) > > Authors: Oliver Terbu > > Daniel Fett > > Brian Campbell > > Name: draft-ietf-oauth-sd-jwt-vc-06.txt > > Pages: 53 > > Dates: 2024-11-13 > > > > Abstract: > > > > This specification describes data formats as well as validation and > > processing rules to express Verifiable Credentials with JSON payloads > > with and without selective disclosure based on the SD-JWT > > [I-D.ietf-oauth-selective-disclosure-jwt] format. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-06.html > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-sd-jwt-vc-06 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > OAuth mailing list -- oauth@ietf.org > > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > -- _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._
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
