I agree with Watson. I also don't understand what delays in the work would occur as a consequence of managing it in a different group.
On Fri, Nov 3, 2023, 9:49 AM <hannes.tschofe...@gmx.net> wrote: > Hi Denis, > > > > It is true that the current OAuth charter does not address the three party > model. > > > > This is why Rifaat and I have put an agenda item to the OAuth meeting to > discuss a charter update. We will talk about this new charter on Tuesday > after the WIMSE and the SPICE BOFs took place. > > > > Ciao > > Hannes > > > > *From:* Denis <denis.i...@free.fr> > *Sent:* Mittwoch, 1. November 2023 19:18 > *To:* Hannes Tschofenig <hannes.tschofe...@gmx.net> > *Cc:* sp...@ietf.org; oauth <oauth@ietf.org> > *Subject:* Re: [SPICE] [OAUTH-WG] Relationship between SPICE and OAuth > > > > Hi Hannes, > > > > The current charter of the OAuth WG is available at: > https://datatracker.ietf.org/wg/oauth/about/ > > The major problem is that both this charter and the OAuth 2.1 (or OAuth > 2.0) authorization framework > cannot currently address the three roles model with an Holder, an Issuer > and Verifier. In the three roles model, > there is no concept of a "resource owner ", nor of a "resource owner's > consent". > > Bridging the architectural narrative used in the core OAuth framework (AS, > RS, RO) and in the three roles model > (Holder, Issuer, Verifier) would not be appropriate. > > As Justin mentioned in https://oauth.net/articles/authentication/: > > "Remember, since OAuth is a delegation protocol, this is fundamental > to its design". > "In OAuth, the token is designed to be opaque to the client, but in > the context of a user authentication, > the client needs to be able to derive some information from the > token". > > The current draft from "The OAuth 2.1 Authorization Framework" states in > section 1.4 > ( > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-access-token > ): > > "An access token is a string representing an authorization issued > to the client. > The string is considered opaque to the client, even if it has a > structure". > > When using selective disclosure, the access token cannot remain opaque to > the client since it needs to be opened and modified by the client. > "Selective disclosure" is not a requirement: it is one mechanism that > allows to support the privacy principle of "collection limitation", > i.e., limiting the collection of end-users attributes to that which is > strictly necessary for the specified purpose(s). > > However, "selectively disclosable claims" is only the tip of the "three > roles model" iceberg, since other disclosure mechanisms, e.g., based on > zero knowledge techniques > can be used and several privacy and security properties need to be > considered. With some models, some properties can be supported, while with > other models they can't. > > The OAuth 2.0/2.1 framework cannot apply to a three roles model with an > Holder, an Issuer and Verifier. Rather than working with document > increments > based on the OAuth 2.0/2.1 framework, a re-chartering the OAuth working > group would be necessary so that a framework tailored to the vocabulary > of three roles model could then be developed. > > It should finally be noticed that the acronym of this WG, "OAuth", is a > short for "Open Authorization". It is questionable whether that acronym or > its meaning > would still be appropriate to address the three roles model which does not > fit into the OAuth 2.0/2.1 framework. > > Note: On the SPICE BoF mailing list, I raised an issue and proposed an > alternative strawman proposal for the spice-charter > (https://github.com/transmute-industries/ietf-spice-charter/issues/3). I > also sent several emails requesting changes to the wording of the proposed > charter. > Please note that at this time, I don't agree with the current wording of > the SPICE BoF charter. > > > Denis > > > > Hi Hannes, > > Am 1. Nov. 2023, 12:21 +0100 schrieb Hannes Tschofenig > <hannes.tschofe...@gmx.net> <hannes.tschofe...@gmx.net>: > > Hi all, > > I am a bit puzzled by the response Pam and I received when putting the > agenda for the SPICE BOF together. It appears that most people have not > paid attention to the discussions during the last few months. > > Let me try to get you up to speed. So, here is my summary. > > The OAuth working group has seen a lot of interest in the context of the > SD-JWT/VC work and there have been complaints about the three WG sessions > we scheduled at the last IETF meeting. (FWIW neither Rifaat nor I > understood why we received these complaints given that people asked us for > more slots. But that's another story...) > > The SD-JWT/VC work is architecturally different to the classical OAuth > (which is not a problem) but raises questions about the scope of the work > done in the OAuth working group, as defined by the charter. The charter of > a group is a "contract" with the steering committee (IESG) about the work > we are supposed to be doing. There is the expectation that the work > described in the charter and in the milestones somehow matches the work the > group is doing (at least to some approximation). See also the mail from > Roman to the OAuth list for the type of questions that surfaced: > https://mailarchive.ietf.org/arch/msg/oauth/a_MEz2SqU7JYEw3gKxKzSrRlQFA/ > In time for the Prague IETF meeting a BOF request (with the shiny name > SPICE, see > https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/) > was submitted. It was subsequently approved by the IESG. SPICE aims to > cover the scope of the SD-JWT/VC work (plus work on defining the CWT-based > counterparts) -- my rough summary; details are here: > https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md > > This BOF request again raised questions about the scope and the > relationship with OAuth, see Roman's note here: > https://mailarchive.ietf.org/arch/msg/spice/Aoe86A0x6bezllwx17Xd5TOQ3Pc/ > Now, we are in the final stages of preparing the BOF for the Prague IETF > and in the agenda preparation we repeately get asked the same question: > > "Has the transfer of some of the OAuth documents already been agreed?" > > The answer is "no". Nothing has been agreed. The purpose of the BOF is to > find this agreement. > > So, if you have an opinion whether some of the OAuth documents (in > particular draft-ietf-oauth-sd-jwt-vc, > draft-ietf-oauth-selective-disclosure-jwt, draft-ietf-oauth-status-list) > should move to a new working group then you should speak up **now**. > > Have a missed a posting on this list where you have started a discussion > with the WG of whether the drafts shall be moved into SPICE now? Otherwise > I’m wondering about the tone of your post. It’s the WG that needs to decide > on this topic, right? It’s not up to the WG chairs to do so. > > > The SPICE BOF (and the WIMSE BOF) will happen on Tuesday next week. The > first OAuth WG session happens shortly afterwards (also on Tuesday). The > outcome of the BOF(s) will guide us in our discussion about re-chartering > the OAuth working group (which is an item on the OAuth agenda, see > https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-03). > > Rifaat, Pam and I are mediators in this process and therefore we rely on > your input. Since you have to do the work, you should think about where you > want to do it. > > Ciao > Hannes > > PS: A process-related note. If you are author of a working group document > you are working for the group. With the transition from an individual > document to a working group document you have relinquished control to the > group. While your opinion is important, it has the same weight as the > opinion of any other working group participant. The theme is "We reject: > kings, presidents, and voting. We believe in: rough consensus and running > code". > > Absolutely. So let’s have a discussion in the WG. > > best regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > SPICE mailing list > sp...@ietf.org > https://www.ietf.org/mailman/listinfo/spice >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
