Re: [jose] An attempt at unlinkable tokens with minimal magic
Orie Steele <orie@transmute.industries> Tue, 02 August 2022 13:00 UTC
Return-Path: <orie@transmute.industries>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694A5C13CCE8 for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 06:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
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 8h7vzzDU_hUm for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 06:00:36 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 95E6DC14CF05 for <jose@ietf.org>; Tue, 2 Aug 2022 06:00:36 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id h28so7140865pfq.11 for <jose@ietf.org>; Tue, 02 Aug 2022 06:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLntmV5ygezeZqPnZeNbeNeZxgASuTJOlg2Pe73r8cc=; b=JM3jrDJ8E6t9gSwB0Z+rHhgarQVAYif16LzlvvJiqMs75wj59SyDYS/USBm6S2t5hv ZFBG/Tv5TxT5d0ENe9l1fUTZnAbPUW1hN1qjZltFRBh5HCNoHBtItTK87W3BR19U8KW6 lFAzRppG3nrIlpOZ71aOeNoJJN+DNdIHe6JGo7YPD2uhclzu3HDcBQ+j8OXsWLUQi4yX xA1/KMjBe5SJ/P2l8gknUjklZTFQIKUN5o5AZEnMzvsBaODMOI0vaH3uIu9DMDIEtm4B FQVUMpOC1VaN4lmozlo0GturAbk2xNv2oU+cKERctoSNJvc3CQuvJVpJRiEt0TxLGQSF 2NCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oLntmV5ygezeZqPnZeNbeNeZxgASuTJOlg2Pe73r8cc=; b=2+U6NVNCBsRSL39X4s6T5jcKJSDGbTvg/WM5I0aVDfzzsonf9JSZMdiIm+OYWY1MzW 1bH15H8WSzXng4q1J991nqShkIAOk6PqXeiNCzLULrEjKUV5ICTSqwhFq9F8JpiRhQeF M1tKUc9+q/pMrUTKmn5ZnuEAfj/S/UO9Ejljv1ADxE4s5OcktIpZ1USrZrS1OpeHJS4Q MRTSGz+tRLyGkdUv6xZeqyGks1PFQIJvpmn6va50XRGH2ccJPSLSXOuLFILdYBkYabpf AiwgVqpYXFyLgwqXdNHbye5nN84BGV7mcSpBvvPBFmb1Kf+YSzXFXFDZC8oHAkW0NBOo 4sFg==
X-Gm-Message-State: ACgBeo0+FzY9uliXoj+Sm1dhVjnlldE1n1zpGvJvhx05ySgo3V/PB9IC C0MugPHcObhPOxuhkI6LHn3OPl4ofmrYtDPv/hbBvw==
X-Google-Smtp-Source: AA6agR67FAvMFDQ3d8bH+kL73AB0PW9Mjbsgdo2GlUDmv3wM5FTj6pHpCV6Dhlu6LLLmzKFWl51vGc3HT1oH7NrKnzw=
X-Received: by 2002:a62:1a56:0:b0:52d:4352:3ae0 with SMTP id a83-20020a621a56000000b0052d43523ae0mr12022147pfa.35.1659445235372; Tue, 02 Aug 2022 06:00:35 -0700 (PDT)
MIME-Version: 1.0
References: <ME4P282MB0984F3582C4BD1707B86C8068E969@ME4P282MB0984.AUSP282.PROD.OUTLOOK.COM> <3D04F1F0-ACA2-402D-94B5-BB227126CFAE@forgerock.com> <CAAFNpxu0=MEwnUTtgxuU48aJVmFODwu=oLBOwxEevoa=r1iZFw@mail.gmail.com> <FA054BF3-440B-43E8-81B5-42BDADC14498@forgerock.com>
In-Reply-To: <FA054BF3-440B-43E8-81B5-42BDADC14498@forgerock.com>
From: Orie Steele <orie@transmute.industries>
Date: Tue, 02 Aug 2022 08:00:23 -0500
Message-ID: <CAN8C-_JD7FjGkiP_SmyWBJpKtM33Fkmm97u9u3v3UM_6MrPr5Q@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Jeremie Miller <jeremie.miller@gmail.com>, Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org>, jose@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c772e905e541b3cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/M517lW_ENWoNat8zzDoGPJwZ4Rw>
Subject: Re: [jose] An attempt at unlinkable tokens with minimal magic
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 13:00:41 -0000
Good security is about building the right layers. Many of these arguments might be better focused in the CFRG. I wonder if the argument in this thread might be some version of denying the problem... If we are going to do modern cryptography, we will either have a standard json representation or we won't. If the assertion is, let's not use that cryptography... That's not exactly an argument against the envelope format. I am in favor or resurrecting JOSE and defining JWP. Regards, OS On Tue, Aug 2, 2022, 4:51 AM Neil Madden <neil.madden@forgerock.com> wrote: > On 30 Jul 2022, at 18:26, Jeremie Miller <jeremie.miller@gmail.com> wrote: > > > Isn’t this somewhat overstating the likely privacy benefits? If the prover >> reveals _any_ PII to the verifier then the verifier can collaborate with >> the issuer to discover everything about that user. >> > > JWP as a container aims to make unlinkability _possible_ for applications > to build, not a guarantee. There are many extremes an application may > choose to design for to accomplish different scales of unlinkability (from > multiple verifiers colluding, from the verifier and issuer colluding, from > multiple presentations to the same verifier, etc). > > In my mind it's akin to you can cryptographically validate the contents > and signature in a JWS, but how you decide if you trust the signer is up to > the application or higher level protocols. > > And we know from many studies on deanonymisation that it is very easy to >> accidentally reveal enough information to be identifiable. ZK proofs are >> nice and everything but they only ensure zero *additional* knowledge is >> gained by the verifier. In practice what is explicitly revealed is often >> enough. >> > > That's exactly why we believe this work is very important, having a > container to support algorithms where zero *additional* knowledge is > revealed by the container and crypto layers. > > It *is* very easy to incidentally reveal linkable factors, which is why > JWP is hard to get right, and critical to do so to enable this capability. > > IMO if you want to have any hope of actually achieving the privacy you >> want then you really need to design the entire protocol, including >> specifying exactly what information is to be revealed. I think designing a >> generic “privacy preserving” message container is likely to give people >> unrealistic expectations. >> > > We have the lowest level privacy algorithms becoming well established like > BBS (and CL signatures, etc), next we need a privacy-capable container to > make those algorithms more accessible and interoperable, then we need > privacy protocols to leverage those containers, then privacy aware > applications, ecosystems, and user experiences. > > > I think perhaps we most fundamentally disagree on this roadmap. Although > many standardised systems have followed this kind of modular design, I > don’t think it is the best approach. Compare say IPSec vs WireGuard for an > often-cited example. Privacy is not a separable concern. Start with the > privacy-aware applications. Otherwise I think we’ll end up with lots of > “privacy-related” tools with lots of sharp edges that inevitably get used > inappropriately. > > — Neil > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
- [jose] An attempt at unlinkable tokens with minim… Vasileios Kalos
- Re: [jose] An attempt at unlinkable tokens with m… Neil Madden
- Re: [jose] An attempt at unlinkable tokens with m… Tobias Looker
- Re: [jose] An attempt at unlinkable tokens with m… Jeremie Miller
- Re: [jose] An attempt at unlinkable tokens with m… Neil Madden
- Re: [jose] An attempt at unlinkable tokens with m… Orie Steele
- Re: [jose] An attempt at unlinkable tokens with m… Zundel, Brent
- Re: [jose] An attempt at unlinkable tokens with m… Mike Jones
- Re: [jose] An attempt at unlinkable tokens with m… Vasileios Kalos
- Re: [jose] An attempt at unlinkable tokens with m… Pieter Kasselman