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

[Dick Hardt <[e-mail]>]

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 <[e-mail]> 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 <[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
>>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>