Fully agree to Markus. The interoperable implementations exist: Recommend that
experts from those implementations contribute to allegedly missed sections.
Beside this, 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.
So as Markus mentioned: A major change was done without appropriate consensus
which is against IETF rules.
Best
Steffen
Von: Markus Sabadello <mar...@danubetech.com>
Gesendet: Montag, 18. November 2024 10:39
An: Michael Jones <michael_b_jo...@hotmail.com>; 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.
Mike,
Repeating these false claims over and over again about DIDs being
non-interoperable doesn't make it more true.
There are many interoperable implementations based on DIDs, e.g. see in EBSI
VECTOR, TRACE4EU, US DHS SVIP, TruAge, California DMV, BlueSky, Bhutan NDI,
Velocity Network, TBD, Dock, Cheqd, and many more.
And besides, that's not really the point here; the point is that a substantive
change was made arbitrarily, without consensus, while arguments and concerns
were simply ignored, etc. (see below)
Markus
On 11/15/24 3:14 AM, Michael Jones wrote:
For what it’s worth, I agree with the editors that the previous text on using
DIDs was not sufficient to enable interoperable implementations – which is the
point of standardization. It seemed like a practical simplification and
engineering improvement facilitating more interoperability to remove the
non-actionable text.
My two cents worth,
-- Mike
From: Markus Sabadello <mar...@danubetech.com><mailto:mar...@danubetech.com>
Sent: Thursday, November 14, 2024 11:11 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [OAUTH-WG] Re: I-D Action: draft-ietf-oauth-sd-jwt-vc-06.txt
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<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<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
