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

[Denis <[e-mail]>]

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]>:
>
>     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
>
>