This kind of response is consistent with the behavior we have seen on this topic so far, simply ignoring and brushing aside concrete arguments and statements that are obviously "tiresome" to the editors.

At least admit that you made a mistake by declaring "consensus" in the group, when that obviously didn't exist, Brian.

Markus

On 11/18/24 2:10 PM, Brian Campbell wrote:
Much has been made in this thread about consensus and the publication of drafts. Despite some apparent misunderstandings here, Internet-Drafts (I-Ds) are in fact a foundational component of the IETF’s consensus building and standards development process. Congruent with that process, I would suggest that those advocating for treatment of W3C's DIDs in the IETF write an Internet-Draft and utilize that as a vehicle for input into the standards process.


On Thu, Nov 14, 2024 at 12:11 PM Markus Sabadello <mar...@danubetech.com> wrote:

    Daniel,

    I looked at https://datatracker.ietf.org/doc/html/rfc7282, and I
    don't think it's appropriate to declare "rough consensus" in this
    case.

    There have been a significant number of people who articulated
    many concrete arguments why it would be a bad idea to drop DID
    support.

    The editors didn't consider or address any of those arguments, or
    provide meaningful counter-arguments.
    Instead they dismissed substantive arguments as "general advocacy
    for the wonders of DIDs", they labeled DIDs as "stuff that doesn't
    work anyway", they declared that "there were no real objections
    other than DIDs are great", and called the issue "tiresome".
    Many of the editors' comments on this topic were passive
    aggressive, provocative, dismissive.

    PR 251 was created with a deceptive title, without description,
    and without reference to the issue where the discussion was taking
    place, in an obvious attempt to mislead contributors, and to avoid
    attention and discussion.
    After merging against objections, other related issues were
    quickly closed as "overcome by events".

    In order to not just provide a one-sided perspective, as a DID
    supporter, I can actually understand concerns about DIDs in SD-JWT
    VC being underspecified (we can help address that), and in fact I
    have also seen good arguments why it may indeed make sense to move
    DID support into a separate specification (e.g. in this comment
    https://github.com/openid/OpenID4VP/issues/278#issuecomment-2422455336).

    But the way how this topic has been handled and dismissed is not okay.

    To say "drafts can be changed any time" is a weak excuse for this
    behavior, and to try to find rough consensus on a mailing list
    AFTER a change has been made is not okay either.

    To say "nothing breaks, because it's all extensible and you can
    define your own profile" may or may not be true, but certainly
    doesn't justify making arbitrary changes despite objections.

    The PR should be reverted, and corresponding issues re-opened,
    until consensus has been achieved, in order to avoid further
    damage to this work.

    Markus

    On 11/14/24 7:00 PM, Daniel Fett wrote:

    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
    *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 tooauth-le...@ietf.org


    _______________________________________________
    OAuth mailing list --oauth@ietf.org
    To unsubscribe send an email tooauth-le...@ietf.org

    _______________________________________________
    OAuth mailing list --oauth@ietf.org
    To unsubscribe send an email tooauth-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

Reply via email to