Re: [jose] An attempt at unlinkable tokens with minimal magic

Jeremie Miller <jeremie.miller@gmail.com> Sat, 30 July 2022 17:26 UTC

Return-Path: <jeremie.miller@gmail.com>
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 E4FCDC14CF06 for <jose@ietfa.amsl.com>; Sat, 30 Jul 2022 10:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 dL4XtWNoCpwo for <jose@ietfa.amsl.com>; Sat, 30 Jul 2022 10:26:48 -0700 (PDT)
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 0752CC14CF05 for <jose@ietf.org>; Sat, 30 Jul 2022 10:26:48 -0700 (PDT)
Received: by mail-oo1-xc2a.google.com with SMTP id v5-20020a4aa505000000b00435b0bb4227so1317876ook.12 for <jose@ietf.org>; Sat, 30 Jul 2022 10:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fjrVImyLPTwMfABu49kW94+Du7Ssx3CX8H7mF1UQeBA=; b=WOqxU5vT+COORdmzYHfrbp9KmnZ6XdULL7h81/uf+YpMeo/+r0xk+C33LWT/yHzJVz 6tG5fdNW2Atvm1vz+7DthUQbFnzflIF3EEHi8W1DJPk3J5sey3xC5LlVegLSJoi5OrLa dXFaifYMQ0iX8sGgG0msdH5gSNkf4WkdyfVD/WY2Cr/WqJ1pyfEYQNjI+tLrerXfJKpv aGJSQF0Ev2LC2EFRx2aavJGk0fkksqcV+UFfY2KJzu1Xay1kpYImLV++gPcI+RvodgFE xRdcrl8uumIR8stAJVQbajlW80P5TwxAvHp5lPjNkR+1wDRhWuIKQXOkrQTH7KDLLIHs zhQw==
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=fjrVImyLPTwMfABu49kW94+Du7Ssx3CX8H7mF1UQeBA=; b=DdZOLA11Q2NBbBAwGfgSqeEH2+HMXQGvkyCpSAPDElRlTJtsrMiDeEi/m/6Le9lamE GmrL/zabdqlQCx0X09jpjIZaOQo84DVJpD9NrmtPbJ4RW6m1fnFjzdKlf+Q4jbj3QOXH r3ufNFP8m05fnAc7BqKzZxlHXPye0Xot2xWoTpw1ohT9AyLwJP04evIMdcTC/JhJXqHN qNRCDBmGDNKLd0akR70ji8ptWzhHaYPZs7IBVM7X5Qw5CKAk6mBbN8AvvPMxgL21kL5z s/8t7TI6esyANMn7fYJi3oC6HzqoLGULJmLoQR1CwHnlTXiNkXmrpBpHqcn1pRsVJsTL TFmg==
X-Gm-Message-State: AJIora/Es7M60v1bcnGnh33j0ME0oE0UZ5bH0p6/GvQkoWpgOjyATKwh +WP/cQ9CI3U7Wgq9DVLq1xtmz0dfB/bn21UxwMc=
X-Google-Smtp-Source: AGRyM1sHtChgwjGeK8MkjwCU1iHXrRdplTiBZgnj6oMg3SlM/X5oegvJyOpiWjPC/BJjCm2UimgegDZxQjPyFUNCyWU=
X-Received: by 2002:a05:6820:619:b0:435:9143:176e with SMTP id e25-20020a056820061900b004359143176emr3081047oow.95.1659202006568; Sat, 30 Jul 2022 10:26:46 -0700 (PDT)
MIME-Version: 1.0
References: <ME4P282MB0984F3582C4BD1707B86C8068E969@ME4P282MB0984.AUSP282.PROD.OUTLOOK.COM> <3D04F1F0-ACA2-402D-94B5-BB227126CFAE@forgerock.com>
In-Reply-To: <3D04F1F0-ACA2-402D-94B5-BB227126CFAE@forgerock.com>
From: Jeremie Miller <jeremie.miller@gmail.com>
Date: Sat, 30 Jul 2022 11:26:35 -0600
Message-ID: <CAAFNpxu0=MEwnUTtgxuU48aJVmFODwu=oLBOwxEevoa=r1iZFw@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org>, jose@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003653d105e509122f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/oCCbzMBYHo_iy89BW-0NAgCywao>
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: Sat, 30 Jul 2022 17:26:51 -0000

>
> 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.

Jer