[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-sd-jwt-vc-06.txt

[Steffen Schwalm <[e-mail]>]

Hi Daniel,

first of all to be honest the tone of your message is surprising as you mention assumptions like “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.”. Who is we? You personally? The experts? Looking in [1] it seens like your personal opinion but I might be wrong. Means you deleted DID reference obviously without consulting all experts but I might be wrong.

I refer to [1] (comment from Brian Campbell) where an consensus is assumed which, if you look at the discussion, obviously does no exist. Means you created your draft obviously without consensus. Regarding the other stuff:


  *   Section 1 of RFC 2026 defines “These procedures are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Internet Standard. At each stage of the standardization process, a specification is repeatedly discussed and its merits debated in open meetings and/or public electronic mailing lists, and it is made available for review via world-wide  on-line directories” The fact that somebody of the Authors assumes a consensus while parts of WG protests makes obvious that a fair and open process seemingly not really existed, same with the open debates etc. Seems more that the authors decided to finalized the new draft, ignoring opposite opinions. So exactly this obviously missing consensus or alignment with the experts during drafting is missing – otherwise there won`t be those protests in GitHub

  *   Would be breach of Section 1 RFC 2026.

  *   Beside RFC 2026 I refer to RFC 8874 valid your drafting of your own document “More mature documents require not only consensus, but consensus about specific text. Ideally, substantive changes to documents that have passed WGLC are proposed as pull requests and MUST be discussed on the mailing list. Having chairs explicitly confirm consensus on changes ensures that previous consensus decisions are not overturned without cause. Chairs MAY institute this stricter process prior to WGLC..



     *   As you obviously have no consensus you are on breach of your own rules as Deleting DID References is mature change!
     *   Decision about this is not in hands of authors as Brian Campbell seemingly assumes
     *   If I have overseen the related discussion etc. please point me to it
  *   RFC 7282 Section 3
     *   According to Section 3 of RFC7282<https://datatracker.ietf.org/doc/html/rfc7282#section-3>, rough consensus can be achieved when all issues are addressed, but not necessarily accommodated:
     *   But Section 3 also defines: “What can't happen    is that the chair bases their decision solely on hearing a large number of voices simply saying, "The objection isn't valid."  That would simply be to take a vote.  A valid justification needs to be made.”



Exactly this was, looking at the discussion in GitHub, not done.

  *
If you now try to achieve this rough consensus, this would solve the issues on Section 5 and 9.2 but unfortunately your draft is in breach of RFC 8874 as assumption that for drafts no consensus needed is IMHO wrong as it`s a major change to delete the DID references. Beside this you are in Breach of RFC 2026 Section 1 and 2.

Would recommend you withdraw your draft and start the discussion in GitHub again as a draft which is obviously developed in Breach of several IETF rules seems not the best basement for discussion in Mailinglist acc. Section 5 RFC 2026.

A formal appeal against your approach will be started if we can´t find a consensual solution.

Best
Steffen




Von: Daniel Fett <mail=[e-mail]>
Gesendet: Donnerstag, 14. November 2024 18:01
An: [e-mail]
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.

Steffen,

I am surprised and somewhat startled by the tone in your message. My message to this list was clearly intended to find the rough consensus that is missing - that's why I pointed to the two threads of discussions - and not to ignore the usual IETF processes.
Am 13.11.24 um 22:34 schrieb Steffen Schwalm:
great work! Looking at [1] and [2] there`s obviously no consensus – which implies a breach of Sections 1.2, 5 and 9.2 of the IETF Directives on Internet Standards Process.
These are strong accusations. I presume you're referring to RFC 2026<https://datatracker.ietf.org/doc/html/rfc2026>? How would Sections 5 and 9.2 apply here, even remotely?

An assumption is great but not sufficient as in any standardization body.

Again, finding this consensus is precisely what my previous message intended. Maybe this got lost in translation.
According to IETF rules the consensus shall be ensured before announcement of new version.

In my understanding and experience in this group, draft versions are just that - drafts. They can be changed at any time and this can include reverting previous changes if the working group comes to the conclusion that that is required. A new draft version can be the trigger to start a discussion to find rough consensus on a specific topic.

As far as I know, there is no part in the IETF rules that says that consensus on any change must be ensured before publication of a new draft version.
 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. 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.
As above - this discussion is exactly what I wanted to trigger. It needs to happen here on this list. If the outcome is that the DID references should be preserved, we'll do so.

 Formal appeal acc. Section 6.5 of IETF Directives on Internet Standards Process will follow in case the IETF directives will still be ignored.

Ok.

-Daniel

Best
Steffen

Von: Daniel Fett <mail=[e-mail]><mailto:mail=[e-mail]>
Gesendet: Mittwoch, 13. November 2024 21:03
An: [e-mail]<mailto:[e-mail]>
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 [e-mail]<mailto:[e-mail]>:

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 -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



_______________________________________________

OAuth mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>