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=40danielfett...@dmarc.ietf.org>
Gesendet: Donnerstag, 14. November 2024 18:01
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.

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=40danielfett...@dmarc.ietf.org><mailto:mail=40danielfett...@dmarc.ietf.org>
Gesendet: Mittwoch, 13. November 2024 21:03
An: oauth@ietf.org<mailto: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<mailto: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<mailto:oauth@ietf.org>

To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>



_______________________________________________

OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>

To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to