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

David Waite <david@alkaline-solutions.com> Thu, 28 July 2022 22:42 UTC

Return-Path: <david@alkaline-solutions.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 52F73C1C767B for <jose@ietfa.amsl.com>; Thu, 28 Jul 2022 15:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 UyR_1GW2sBp2 for <jose@ietfa.amsl.com>; Thu, 28 Jul 2022 15:42:27 -0700 (PDT)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (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 5B524C1C7678 for <jose@ietf.org>; Thu, 28 Jul 2022 15:42:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1659048145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ur5TUhvMiadGBziI+a9Dscd2ESP6/THX1eME+EDfFo=; b=CVORMT/sAIZx6Bl80DIzy946tNtDWnPDO5jEQjce2BOopw0twoD8IGZd7mpngX1H5Y1dVN utRJPiW+3E+iIjFPlbLkbZB2GncCtWpYF9mB4GUufk82r9mh6XBuaTypJMRU8rH5xRJo9/ fCxI0oHh38p87gXsaAukLCbaMoYRNRI=
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CAL02cgQMqeac=FWuh1fwUG6UrCtM7pggCGt6X3thy4dNGTTJLw@mail.gmail.com>
Date: Thu, 28 Jul 2022 18:42:10 -0400
Cc: jose@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2401B0C-8D1D-479A-9696-D318CD8ADBDF@alkaline-solutions.com>
References: <CAL02cgQMqeac=FWuh1fwUG6UrCtM7pggCGt6X3thy4dNGTTJLw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Spamd-Bar: /
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/xa2LDM12Nz6BQFeZKTB60wMOCp8>
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: Thu, 28 Jul 2022 22:42:31 -0000


> On Jul 28, 2022, at 5:39 PM, Richard Barnes <rlb@ipv.sx> wrote:
> 

> Supposing such a system exists, consider the following scheme:
> 
> 1. At issuance time, the holder executes the issuance protocol N times, each time with a fresh random subject key pair and fresh blinding of the selective disclosable claims.
> 2. As a result, the holder obtains N credentials with different subject public keys and different signatures
> 3. The holder presents each credential exactly once 
> 4. The holder goes back to step (1) when they need a new pile of credentials
> 
> It seems like this trivial scheme meets most of the requirements I've seen expressed so far:

This is indeed how a single-use unlinkable form using more traditional cryptography should be expected to work, such as in ISO 18013-5 mDL mDocs.

<snip>

> Anyway, it seems like the above system achieves the stated goals of unlinkability and selective disclosure, with no fancy cryptography or new JSON structs required aside from the SD stuff.  What critical requirement is this missing that would motivate a significant new engineering effort?


The most significant one is reliance on an ongoing, active relationship with an issuer, who has online infrastructure for issuance that the holder is authorized to use. This makes them somewhat brittle as a digital replacement for traditional documents in particular use cases.

A more recent example where this is an issue is in various covid vaccination credentials. 

The broadly published credential formats do not anonymously credential the user. Indeed, most actually represent a full medical record, with sensitive data including real names, clinic locations and vaccination history. 

The primary limitation that this resulted from was the infeasibility of having each medical provider run their own issuing infrastructure. In some environments, even if a clinic had such infrastructure it would be infeasible to authenticate users to vend out ongoing single-use credentials as they did not have such a longer-lived relationship with the vaccine receiver. The lack of authentication is a reason for the real name to be included - it can then be correlated with other identity documents such as a passport.

It is also impractical to assume that all clinics will remain operational over the usable lifetime of such a credential.

There are other features which are out of scope for the initial charter which are not feasible with approaches based on typical cryptography, such as privacy-preserving revocation of mis-issued credentials, or releasing predicate proofs of additional calculated information about such a credential (e.g. release “vaccination received less than one year ago” without releasing the exact date and time)

-DW