[OAUTH-WG] Re: SD-JWT linkability

Joseph Heenan <joseph@authlete.com> Tue, 17 December 2024 21:59 UTC

Return-Path: <joseph@authlete.com>
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 5C64FC1516E0 for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2024 13:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20230601.gappssmtp.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 noFgO-4OlzXo for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2024 13:59:28 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1F7C151097 for <oauth@ietf.org>; Tue, 17 Dec 2024 13:59:25 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4361c705434so42188935e9.3 for <oauth@ietf.org>; Tue, 17 Dec 2024 13:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20230601.gappssmtp.com; s=20230601; t=1734472764; x=1735077564; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VZfckdD43HU26UJAkgWFZ4PGy4W05wDszVf10dYV6EE=; b=IMboBPGCYR1V2d8nFVVQfjU1LFCj4oKvMF7AY1oBQZEPCHEh3i4teJUSi16PmtAGbv Q3ntLdsPPvCsdhkdGLZ7wYCHADM31T3aUCI8Fwpo5hCxAB5Z/QpDWqKceyvmn1ZwTict YAV+u0sdz0vJ1zh8j1DhmW+HoGW05GLltK3jU9svPm2l9/ybTX3La+knmj8B2f8MGlVa 6dtWo95IP7xIEKLJVUagTwLv3gH+n2vNay03hoFnnUjEkQVyNHyUtDiQSIlOLkZrkBjy ltUPozHKVZHlggudCkwPKIaIpdK6HMWHsxUEMXyh4qJEzgp9+fYFrr6LJxZ0NIB0xNSc 3czA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734472764; x=1735077564; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VZfckdD43HU26UJAkgWFZ4PGy4W05wDszVf10dYV6EE=; b=n7/8SJzxigJDWDO3HrTu4ZVunCp8lUPArIwQHi1ZrQKCaAOcoQmCnu5gAy8F+e/Csq 5kV7vlIFNzdwmSt9TIIHHLtvdHOxBVsXjDIoxVmE2XPbzWvrle5Sw9pVK3reKf+/gCm3 2KEltNFJ/B+X+0P+TjSc8OBw863Zk50u6z+pU3Ae5QY+CpRLypNkpx3Z53U4MLZ6tdAQ bv5REEeTF+8GW03aui23diWmM1xrc32gBlPOymqEguzZJODsuh3RU8Bp2gzifvqOHT3V axwU+LCioNk64oFvx1W6FHmRv5MR9UV5wbcBPHe9aP7CRZXopMZQ1PnLdtT5RWN4XZ8Q HjTw==
X-Gm-Message-State: AOJu0YxbzlWBVHt4cJxds3h3n7H0D3PTuwEHy5wvw+/1Q7nAQ3AR2to6 6frzw4PK1FEfqYN4aKjRp91HoNmuez06r9N/fBsuzmqCCNBWzEHpxX0o1TuWsDQ=
X-Gm-Gg: ASbGncs42wwMWOmwDjgCaSViWc41LiLofpKdFVDS7onHcAXOuKl8CHaw6SdkjUvBnia +DoSCuxpSgRt3K76z7cE13A9MExt7nYDdW7dpzkEk46spM4vgEScS/7RaATzV9TsIIFDqYQhVZo n3YM2Cb4J2a8dQ3+KZCbnTDpmv+vrsaNSGohx+tCziVYJ8w9JQe7I1i7NEIqkhg5L63fpz1Q8EO tKjh/Gwgl/SOG6xX744B78RqzlClgT5NSRsPD8ebBEqGTHXst2M1qT7Azb0nnS35h7f4Wc+zEwM SUuZQn8jiLTMGWhFMca9iJ0rtxeheA==
X-Google-Smtp-Source: AGHT+IGrYFEtmQZ+EECid4UEsKQqIZjuC+IXjYEnjWaC3+Ar+ThqKMlaDSb9gmsFWeI/EXkYszrAxQ==
X-Received: by 2002:a05:600c:4b94:b0:434:fe3c:c67c with SMTP id 5b1f17b1804b1-436553feef4mr2028545e9.26.1734472763875; Tue, 17 Dec 2024 13:59:23 -0800 (PST)
Received: from smtpclient.apple (cust211-dsl93-89-133.idnet.net. [93.89.133.211]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4362557c608sm185394375e9.16.2024.12.17.13.59.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2024 13:59:23 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\))
From: Joseph Heenan <joseph@authlete.com>
In-Reply-To: <CACsn0ckGp4AocD1fQbMCs45P_Z5vjveggzDJw=-Vk5kxinM28Q@mail.gmail.com>
Date: Tue, 17 Dec 2024 21:59:11 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8C86F2E-E288-4799-98BD-108F553C8CFE@authlete.com>
References: <CACsn0ckGp4AocD1fQbMCs45P_Z5vjveggzDJw=-Vk5kxinM28Q@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.3826.300.87.4.3)
Message-ID-Hash: SSKNLRTAZEF4AAWYKETAC2ZJGBSA2FFE
X-Message-ID-Hash: SSKNLRTAZEF4AAWYKETAC2ZJGBSA2FFE
X-MailFrom: joseph@authlete.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF oauth WG <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: SD-JWT linkability
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/p4Jrfeb7h659o4JeGJW5y1AMGv0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hi Watson

Just to respond to the suggested text:

> 
> "When disclosures include information easily understood to be
> identifying, users intuitive view of what they are revealing largely
> matches the underlying technical reality. In cases where the
> information being disclosed is not identifying, SD-JWT
> MUST NOT be used as this confusion leads to users making the wrong
> choices.

This sentence is really hard to make sense of and I don’t think implementors will understand it. I’m not convinced I understand it even with the extra context from the threads. I think a MUST NOT is far too strong too, and saying ’SD-JWT’ in particular must not be used it too strong as an SD-JWT where everything is disclosed (or no selective disclosures are present in the issued credential in the first place) is no different to other credentials formats that don’t have selective disclosure.

> Applications cannot assume Verifiers behave properly (RFC
> 3514) and MUST analyze the consequences for such linkage with each
> credential that could be used."

This ‘MUST’ is practically impossible for some implementors - for example, it is impractical for a wallet to make this kind of judgement for each issued credential.


Thanks

Joseph