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
