| I agree with Dick, Watson et al.
To me moving some work around is a natural consequence of the identity area and the 3 party model growing in importance in the IETF and elsewhere.
Given what’s happening in the EU and elsewhere this should not cone as a surprise to anyone.
Cheers Leif
3 nov. 2023 kl. 16:58 skrev Dick Hardt <dick.ha...@gmail.com>:
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.
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.
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 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.
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
|
