Re: [OAUTH-WG] Relationship between SPICE and OAuth
Daniel Fett <fett@danielfett.de> Thu, 02 November 2023 14:42 UTC
Return-Path: <fett@danielfett.de>
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 4219CC151539 for <oauth@ietfa.amsl.com>; Thu, 2 Nov 2023 07:42:42 -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, 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_BLOCKED=0.001, 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=danielfett.de
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 nCy9nuEtMGnA for <oauth@ietfa.amsl.com>; Thu, 2 Nov 2023 07:42:36 -0700 (PDT)
Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 552ECC151099 for <oauth@ietf.org>; Thu, 2 Nov 2023 07:42:35 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4SLmn23hFHz9slG for <oauth@ietf.org>; Thu, 2 Nov 2023 15:42:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=MBO0001; t=1698936150; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=1eTkUFKDgw6meS3vVLM1gufli0Rv2hZhn9VDr4lYHAU=; b=L2ZBvQ6gt+mZDM87+rczxMcg9YC09X9UrmGHdZPDNHWgWpgW6h5sSlRKpJzMJ8BG1O0Zil CHhTRWHc+0+xZPDDqoiregt6euQPgodQc2HLx4HeajvdGevkcTSmEGFXOCnz7zT67MTxeT RNMJy0xzjlKZBToBQ2iTwKVSI+RzpUnSoDHwkGCyqGBhJUoMT+C2na4nRvBPnX+9/3IvHR AJKYJemb5GARJWxcYHaW31pmX1CTtE6jC6djdzL6QsUPMBQs2LpFlvw6LyeEdn+/yNry5P a0UCwl1JuxdgOAawCnyQT8biG2oJY7nMX7NauZ5pjctGZIOeun/89kGRnzM+cQ==
Content-Type: multipart/alternative; boundary="------------6uBZVEQsl8Bta0wM0UBpdGW4"
Message-ID: <2716b938-57f4-434b-8c52-e0608b582939@danielfett.de>
Date: Thu, 02 Nov 2023 15:42:29 +0100
MIME-Version: 1.0
Reply-To: mail@danielfett.de
Content-Language: de-DE
To: oauth@ietf.org
References: <144ae5fd-92ef-474e-bd4b-7c7e3abfc78e@gmx.net> <SJ0PR00MB131896E45F7013DF0CF49990E5A7A@SJ0PR00MB1318.namprd00.prod.outlook.com> <b7a18c6f-b5c0-4ede-9727-59c2b45b4b38@danielfett.de> <e265c131-989b-45ff-9efa-d8b4721959a6@gmx.net> <a76fa071-7c7b-4682-aa97-217a29971889@danielfett.de> <676b249e-f890-4cd0-9699-090cb309a756@gmx.net>
From: Daniel Fett <fett@danielfett.de>
In-Reply-To: <676b249e-f890-4cd0-9699-090cb309a756@gmx.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LwMTX9B1ncvmKQHWUibILWbzdNc>
Subject: Re: [OAUTH-WG] 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: Thu, 02 Nov 2023 14:42:42 -0000
Hi Hannes, Am 02.11.23 um 15:23 schrieb Hannes Tschofenig: > Do you see a need for COSE/CBOR in your use case now? The main selling point of SD-JWT is simplicity, in the sense that it is easy to understand and easy to implement (relative to other credential formats). Both of this is due to the fact that it relies on the very well-known JWT/JWS specs with many good libraries available. I have personally not heard demand for COSE/CBOR-based formats, maybe because SD-JWT is already serving the existing use cases quite fine and people are less familiar with COSE/CBOR. > Do you have other (maybe new) use cases that rely on COSE/CBOR? > I don't, but maybe others do? -Daniel > > As you can see, I am trying to find out whether there are real-world > use cases that require us to do this work or whether we just do it > because it can be done. > > > Ciao > > Hannes > > > PS: A little bit of background for my questions: A few years ago the > ACE working group was formed, where several people from the IoT > community saw the need to standardize an authorization architecture. > The idea was to re-use OAuth but the OAuth selected encoding formats > based on JSON were seen as too "heavy" for IoT devices and networks. > As a result, everything was re-defined in CBOR/COSE. CWT was one of > the outcome of that work. > > The idea was nice but the success was below my expectations. > > > Am 02.11.2023 um 13:23 schrieb Daniel Fett: >> >> Hi Hannes, >> >> Am 02.11.23 um 12:46 schrieb Hannes Tschofenig: >>> The question to the authors of the SD-JWT & related documents is: >>> Does a CBOR/COSE serialization provide value in your use cases? >> >> My point of view: It makes sense to define a format enabling SD for >> CBOR/COSE, but it will be more than just a different serialization. >> We had to make a number of choices for SD-JWT to reach the current >> format that is optimized for security, ease of use and compactness. >> Many of these choices were due to details of the encoding, e.g., the >> problems associated with canonical representations of JSON, avoiding >> double-JSON encoding, avoiding double-base64 encoding, the existing >> format for JWTs. >> >> I expect that, due to different features in the underlying format, a >> CBOR-based solution will end up making very different trade-offs. >> This may even extend to providing a different featureset. We >> therefore should not strive to align SD-JWT and a CBOR-based solution >> as much as possible (or even putting them in the same draft), but we >> should attempt to create the best possible SD format for JOSE and, >> independently, the best possible SD format for COSE. Otherwise we >> would create two mediocre formats. >> >> In that sense, I also don't see that SD-JWT should wait for a >> CBOR-based draft to start or even longer. >> >> -Daniel >> >>> >>> Ciao >>> >>> Hannes >>> >>> >>> >>> Am 02.11.2023 um 08:41 schrieb Daniel Fett: >>>> >>>> I second what my co-authors Kristina and Brian said. It is a risk, >>>> and there are a lot of unknowns here. >>>> >>>> I have a similar feeling regarding SD-JWT VC, even though that is >>>> farther away from the finish line. >>>> >>>> And as an attempt to explain some of the responses: I think the >>>> communication here was less than ideal. Even if the authors of the >>>> drafts may have no more say than anyone else, as you pointed out, >>>> getting them on board with the idea before listing the drafts as >>>> "proposed work items" would have helped. >>>> >>>> -Daniel >>>> >>>> Am 01.11.23 um 15:54 schrieb Kristina Yasuda: >>>>> >>>>> Moving a somewhat mature draft to another WG is highly likely slow >>>>> down the progress on that document: there is no guarantee there >>>>> will be an overlap in the WG members, there is a risk that >>>>> discussions that were already resolved to be re-opened to be, etc. >>>>> >>>>> I consider SD-JWT closer to a finish line then a start line and >>>>> would not like its progress being slowed down by moving it to >>>>> another WG at this point of document's lifecycle. I am not in >>>>> favor of moving SD-JWT work to SPICE WG. >>>>> >>>>> Best, >>>>> >>>>> Kristina >>>>> >>>>> *From:*OAuth <oauth-bounces@ietf.org> *On Behalf Of *Hannes Tschofenig >>>>> *Sent:* Wednesday, November 1, 2023 4:21 AM >>>>> *To:* oauth <oauth@ietf.org>; spice@ietf.org >>>>> *Subject:* [OAUTH-WG] Relationship between SPICE and OAuth >>>>> >>>>> 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**. >>>>> >>>>> 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". >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> -- >>>> Please use my new email address:mail@danielfett.de >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> -- >> Please use my new email address:mail@danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Please use my new email address:mail@danielfett.de
- [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