Re: [OAUTH-WG] [SPICE] Relationship between SPICE and OAuth
Brent Zundel <brent.zundel@gmail.com> Fri, 03 November 2023 11:01 UTC
Return-Path: <brent.zundel@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48115C15C280; Fri, 3 Nov 2023 04:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNjLwwdWk4SW; Fri, 3 Nov 2023 04:01:00 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00117C15C2BF; Fri, 3 Nov 2023 04:00:59 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-da819902678so215196276.1; Fri, 03 Nov 2023 04:00:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699009259; x=1699614059; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DQs+N1WdBEUcKlsmQNvz1VFWBrp957zp6q9raLygZw4=; b=dvZOrQw2MDeKtwXiMnqUzR6Qc96dJ+/nf2Q/xQaYCuGm0Cn8+/AmAW+MoWr9IaiU02 HJVObn1tmvUa//4ysZ1LNgbeWzCLEcw1EjitK+YlosKtR6ZziflcsIIWOpisOZXKKy67 Yx2bie/UPaG3Q2l+eOmZvQwCnd0ehA+SMFiMMeu/yl9q7CTGqSbF+qvzbBE8/DamaSrL 59CW49Or+ObKbffzaQ80LimAYGFy0DrkyG0/089ik8rKCzFPX5dESDq1MF5ilMNMHCF9 KBLb7GLQYoT8/5XJe6Bd/CuuLNG1KkvCIg1oBhn51lOaZ2433mrPjJIDjciGHtpO4mdX PVbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699009259; x=1699614059; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DQs+N1WdBEUcKlsmQNvz1VFWBrp957zp6q9raLygZw4=; b=miSHS0rQXi9cOv5yWXIw2UktT8lr78UJVpydg/Jf+ff+S4iIRaQUgQVFc5R+ziBHYS u2iRPMBqHYe3sa4t4Pt3qqGaouo84brKppPqakqHqziNvAWrfwcEKrbet8x5KodG2H54 x7nHJffqL5ZyRLXMKdj0c5OsTgJaux9ndwwDolYQZ7ygMXcN34jgo6Y61O6flW/OSLh9 1csZXxRT0K+pDQV26J1Us4qa0B2jMcBiH+3yw3bJ/wEIKNReeVdQtoqmlZ1owhOzefOa 2s8KamHjxl+lJc0RMz0sPNPEFXEPui/BcdlsJD1ciZALD41PKGxqNvdvnsZgTIA4BGR4 kz1A==
X-Gm-Message-State: AOJu0YyZ60KL+BGioVgvB/AonYdOImD8n2ZKEc58jYTOQXpge+k9wPlR onboG9lIikitXAJ+rlrzLOjo8AXn+qQhDK+tA6SjveYK8gM=
X-Google-Smtp-Source: AGHT+IEpbsppM9LL8USS4ClmUMbsKDhvt2hGAc2pvKNVe+FdMUXdWgh8Iv6GZZagP7wGBsIOwOlqpJLXqaj+Vcz+PCo=
X-Received: by 2002:a25:adc8:0:b0:d86:2cd4:c443 with SMTP id d8-20020a25adc8000000b00d862cd4c443mr21701631ybe.21.1699009258690; Fri, 03 Nov 2023 04:00:58 -0700 (PDT)
MIME-Version: 1.0
References: <144ae5fd-92ef-474e-bd4b-7c7e3abfc78e@gmx.net> <3b7b2292-02bb-4ac3-adf0-7e1edf25eb99@Spark> <1a09e91a-12fd-5c47-ad49-88e040a41383@free.fr> <024401da0e32$acf08b10$06d1a130$@gmx.net>
In-Reply-To: <024401da0e32$acf08b10$06d1a130$@gmx.net>
From: Brent Zundel <brent.zundel@gmail.com>
Date: Fri, 03 Nov 2023 05:00:47 -0600
Message-ID: <CAOGO=oEQY1gQjysCFm=ysyNTW259-Ne9uEe3mi1n4h+8YC+3jw@mail.gmail.com>
To: hannes.tschofenig@gmx.net
Cc: Denis <denis.ietf@free.fr>, spice@ietf.org, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055a0b206093d6b18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0_R4R3DffI2CwluYnJho1qoy_KQ>
Subject: Re: [OAUTH-WG] [SPICE] Relationship between SPICE and OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2023 11:01:05 -0000
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 <hannes.tschofenig@gmx.net> 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 <denis.ietf@free.fr> > *Sent:* Mittwoch, 1. November 2023 19:18 > *To:* Hannes Tschofenig <hannes.tschofenig@gmx.net> > *Cc:* spice@ietf.org; oauth <oauth@ietf.org> > *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 > <hannes.tschofenig@gmx.net> <hannes.tschofenig@gmx.net>: > > 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 > SPICE@ietf.org > https://www.ietf.org/mailman/listinfo/spice >
- [OAUTH-WG] Relationship between SPICE and OAuth Hannes Tschofenig
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Kristina Yasuda
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Orie Steele
- Re: [OAUTH-WG] Relationship between SPICE and OAu… torsten
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Hannes Tschofenig
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Denis
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Dick Hardt
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Daniel Fett
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Orie Steele
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Hannes Tschofenig
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Brian Campbell
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Daniel Fett
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Hannes Tschofenig
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Daniel Fett
- Re: [OAUTH-WG] Relationship between SPICE and OAu… Watson Ladd
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… hannes.tschofenig
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Brent Zundel
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Dick Hardt
- Re: [OAUTH-WG] [SPICE] Relationship between SPICE… Leif Johansson