One source of delays could be different chairs that don't have the same context.
Hard to imagine why the people participating in the oauth group would not keep participating in a spice group. I don't have a strong opinion -- but I am surprised by the angst expressed about having a discussion about moving the work. It would be surprising to NOT have a discussion about moving work in the BoF. Hannes, Rifaat, Pam et al have been doing a stellar job herding the cats and they have always been striving to do what is right for the community. Let's cut them some slack. On Fri, Nov 3, 2023 at 4:01 AM Brent Zundel <brent.zun...@gmail.com> wrote: > 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 >> > -- > 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
