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
<[email protected]>:
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
