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

Neil Madden <neil.madden@forgerock.com> Fri, 29 July 2022 07:18 UTC

Return-Path: <neil.madden@forgerock.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 7B830C15C51F for <jose@ietfa.amsl.com>; Fri, 29 Jul 2022 00:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (1024-bit key) header.d=forgerock.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 dhCzO8AWERTy for <jose@ietfa.amsl.com>; Fri, 29 Jul 2022 00:18:51 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 8CA31C15C511 for <jose@ietf.org>; Fri, 29 Jul 2022 00:18:51 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id tk8so7002971ejc.7 for <jose@ietf.org>; Fri, 29 Jul 2022 00:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=G8oX3mJl0eU5+o8nbAWMY5KMrt7ITJYtGPy6qpjz8qs=; b=ekBQADvjljFyJV0soK2+W8S/8PrPtGk/9dUs3zy6mPL8uFZL0AW62akAIjhHuLGKtH DXaWibh04wzwtPfNipeoH5a45obkxnKWtClPfj/dnzgwu54GBRhQ+WmuPs15XC1MXXXL EoYv20s3XUeczzm3tfHT8zF5TB2kbdXziJk/c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=G8oX3mJl0eU5+o8nbAWMY5KMrt7ITJYtGPy6qpjz8qs=; b=MCfBdLvgxWw+WwWULu/tUWANcOL0N2hxt2QsgsluatBN60cHQF71dR6u4hAIQadJqA R4i5Jhv/VfdkS7wOJilQdb1doT/0NYf/4d2zah0qttAyxvL1ballvZFdSiHct1sFPP8w egBlqtcsr3ULAnccOy5JJBUiKo9RjYOCFE+vPpDQgPCVKHiscSQCE7tfGdm/g8E8oQL2 b9tl1hQ7o+6ZlUKmMwGYgIDRfKpgxQbcWGkE5uA+m6S6r4hBCagmtv/wANcSju2uOeCA P8Jrl8xwvdUU8rRmtrQQ55zaIHKiHGH3xbAZQ7UoaKr2uRK7gRROuk11Pw12NCFpVMfW j9oA==
X-Gm-Message-State: AJIora/+eLuLM2+D2qn61UVCOsVktBvKBmy6KBec0dH/KCthqc/Ql8ko elakUV/7Bz+BhVoBwO47oEmSWQ==
X-Google-Smtp-Source: AGRyM1u1bIx/c1t6Ebbsv05z8Fb3OFq0+X1iNZE69YKfmTsKLASEYDRMvr4TWL3oRRt0tkmjKTG9Qg==
X-Received: by 2002:a17:907:1608:b0:72e:e254:7baa with SMTP id hb8-20020a170907160800b0072ee2547baamr1945803ejc.672.1659079129335; Fri, 29 Jul 2022 00:18:49 -0700 (PDT)
Received: from smtpclient.apple (181.213.93.209.dyn.plus.net. [209.93.213.181]) by smtp.gmail.com with ESMTPSA id f11-20020a170906560b00b0072b2eab813fsm1319802ejq.75.2022.07.29.00.18.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 00:18:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-BE83F899-4642-43A5-8B4B-0F1B770FF0D9"
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 29 Jul 2022 08:18:47 +0100
Message-Id: <3D04F1F0-ACA2-402D-94B5-BB227126CFAE@forgerock.com>
References: <ME4P282MB0984F3582C4BD1707B86C8068E969@ME4P282MB0984.AUSP282.PROD.OUTLOOK.COM>
Cc: jose@ietf.org
In-Reply-To: <ME4P282MB0984F3582C4BD1707B86C8068E969@ME4P282MB0984.AUSP282.PROD.OUTLOOK.COM>
To: Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org>
X-Mailer: iPhone Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/qy9DIjOIJNlatHaBb50ggwTqW8k>
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: Fri, 29 Jul 2022 07:18:55 -0000


> On 29 Jul 2022, at 01:44, Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org> wrote:
> 
> Hey all,
> 
> What JWP allows that I find very useful is the following: the Verifier will learn nothing more than what the user reveals, even if they (the Verifier) cooperate with the Issuer (or anyone else).

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

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. 

— Neil