Hi Brian,
thanks a lot for your mail. May you please point me to the rule that only those
people who contributed more than 2 times may advice you to follow your own
rules?
“that describes DID usage with SD-JWT VC (or base SD-JWT or even at the general
JWT/JOSE layer) with language that's sufficient for interoperability” –from
European point of view (CEN) the current text is sufficient.
As you write a IETF standard the RFC 2026 is applicable. I refer to [1]
(comment from you Brian) where you assume a consensus while looking at
discussion it obviously does not 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.
Long Story Short: We appreciate your assumptions but they are wrong according
to your own rules. We would not have to waste our time if the editors of SD-JWT
VC draft would follow IETF Rules and keep the agreements they made with
internal and external parties.
Best
Steffen
Von: Brian Campbell <[email protected]>
Gesendet: Montag, 18. November 2024 12:51
An: Steffen Schwalm <[email protected]>
Cc: Daniel Fett <[email protected]>; [email protected]
Betreff: Re: [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 Steffen,
Thank you for your interest in this work. You've made some strong statements,
particularly regarding IETF procedures and norms—especially for what appears to
be your second
ever<https://mailarchive.ietf.org/arch/search/?as=1&email_list=&end_date=2024-11-14&q=text%3A%28Schwalm%29&qdr=c&start_date=1234-11-10>
contribution to an IETF mailing list. It seems there may be some
misunderstandings or perhaps something lost in translation. With that in mind,
I’ve made an effort to clarify a few points inline below (though this is not an
exhaustive list).
On Wed, Nov 13, 2024 at 2:34 PM Steffen Schwalm
<[email protected]<mailto:[email protected]>> wrote:
Hi Daniel,
great work! Looking at [1] and [2] there`s obviously no consensus
Gauging working group consensus, even rough consensus, is not an easy task.
Despite the accusations levied here, the document editors take that task very
seriously. It is necessarily subjective. And involves considerably more than
github.
– which implies a breach of Sections 1.2, 5 and 9.2 of the IETF Directives on
Internet Standards Process.
Assuming you mean RFC 2026, which has a similar but distinctly different title.
It's a bit unusual to imply a breach of RFC 2026 like that. Section 1.2 is part
of the introduction and seems like an awkward thing to breach. Section 5 is
about the Best Current Practice RFC subseries, which isn't even remotely
applicable to anything at question here. Section 9.2 is about exclusions from
the variance procedure and seems similarly unrelated to the topic at hand.
An assumption is great but not sufficient as in any standardization body.
According to IETF rules the consensus shall be ensured before announcement of
new version.
That is entirely incorrect. Drafts are an integral part of the IETF consensus
process.
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.
That is an opinion offered as fact. And a rather tenuous opinion at that. In my
opinion anyway.
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.
I am not entirely sure what that means, to be honest. But I am reasonably sure
it's not based on anything real. I'd suggest that the relevant experts and DID
proponents write a draft<https://authors.ietf.org/en/home> that describes DID
usage with SD-JWT VC (or base SD-JWT or even at the general JWT/JOSE layer)
with language that's sufficient for interoperability. That work could then be
brought forward for consideration as part of the consensus-building process.
Formal appeal acc. Section 6.5 of IETF Directives on Internet Standards Process
will follow in case the IETF directives will still be ignored.
I am unable to find a document titled "IETF Directives on Internet Standards
Process" so I'll again assume you mean RFC 2026 here. In my reading of Section
6.5 of RFC 2026 The Internet Standards Process -- Revision 3, the appeal
process isn't really intended for challenging discrete revisions of a WG draft.
While your threat has been noted, and I assure you that it has been noted,
before pursuing it, you might first want to carefully consider the
applicability of such action to the matter at hand and the impact on the time
and energy of those required to evaluate it. I can't speak for IETF leadership
(WG chairs, ADs/IESG, IAB, etc.), of course, but I know that I don't typically
appreciate having my time wasted by what appear to be frivolous
misunderstandings.
Best
Steffen
Von: Daniel Fett
<[email protected]<mailto:[email protected]>>
Gesendet: Mittwoch, 13. November 2024 21:03
An: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>:
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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
