Re: [SPICE] [OAUTH-WG] Relationship between SPICE and OAuth

[Brent Zundel <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Mittwoch, 1. November 2023 19:18
> *To:* Hannes Tschofenig <[e-mail]>
> *Cc:* [e-mail]; oauth <[e-mail]>
> *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
> <[e-mail]> <[e-mail]>:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>