[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

Tom Jones <thomasclinganjones@gmail.com> Thu, 26 December 2024 19:35 UTC

Return-Path: <thomasclinganjones@gmail.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 8E684C15108D for <oauth@ietfa.amsl.com>; Thu, 26 Dec 2024 11:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_FONT_FACE_BAD=0.001, HTML_MESSAGE=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 (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 rURCWlg8eyc5 for <oauth@ietfa.amsl.com>; Thu, 26 Dec 2024 11:34:56 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 85E26C151082 for <oauth@ietf.org>; Thu, 26 Dec 2024 11:34:56 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5401b7f7141so6078146e87.1 for <oauth@ietf.org>; Thu, 26 Dec 2024 11:34:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735241694; x=1735846494; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ki3uO5zIo0rvpQEoX+bU7S/k16u+P4k4LpsCiSLDzM0=; b=OrRuod2xn4R3GWKLhQmh4+mj4vSE19Rk/yTN9Gz20QeK0HJro7cT7QUCsvXAEvwEzt +12VkBgOZPpWZyBcZPsX+/FPChDe46+c9hp2ikYYd+AqjklA2pB4aJk6WyzH6J1bQZJt R1e/qalk7nvkB/V7EivFBi5huS9ojSLiVUKqe9DRMohMA8YG55a9fgroSlSPdFyhopw+ 5iZ5OZuws6KDtBJySzY9lY5AkmmSH8G1uKPmldSZTvGLLCEdxjvrUXGzeX2EheiJdeFr v4FfPXfFQYMrp/hpJdVs5+ONvU+TqIsdVBISO+DezmcIakPQsXYkLkA0TR0DYivjymTw f6tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735241694; x=1735846494; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ki3uO5zIo0rvpQEoX+bU7S/k16u+P4k4LpsCiSLDzM0=; b=lWi9AYZaPedY9D5vgEkQXPkv2hP+S873N/+IxnWSB66YxEoqKubtiDXbWLEpDNkjvR BlW1IZOYFjFsghxjKMLyCn5ksaRLQLpxT0ukN5y3LTW7hUjnDsuYKvHxdJibu/5XVRo5 XbvlrQidxxuxKb2CWR5m3Fr9p2UNTXtd7HrRuq6u0VYGvtu//nWzDKLw3dDjACQrT/Lw ljhgiSjBauc9mu8Zrrz4lgdavIIj8wZqXQCTJ7Dng31UWadB5DpvLfeY7l+YvAvC99Z+ pOV0fedNCYEYhdeL40BG9fpY0X9RMqHVPP0S2wDY3XNMot6lzYs24hWDLNpEMfyNfaZD q6Uw==
X-Forwarded-Encrypted: i=1; AJvYcCXBQs5xVQQXzL2bA533pgzXLN55lrjaZo/lfP1j8Lnr72rckbsClaoVk0evMAon4XwGqdpNdQ==@ietf.org
X-Gm-Message-State: AOJu0YzYRT8uYZU1ld84QW/flreYBWcmjL/wHQOL2ANVbIGR/L1vRNvw NCzCu6Ahy0Hr+Eh/7pSiSutYvQ9jjxN0yyN50SL/7d7BPONaDDs5f42cdrA2v6IYvnDYtFT6gFe SqARjnw4Et6XYQyTFUopbuxQYhpBBYg==
X-Gm-Gg: ASbGncu9BU2lptlI9gpanBeSFzJmGjuMlQCABRFcLEvVfouFF4cgH+vKNIgn0RliJje qs1QcGT/Fxebnfo13YZu+Lr9EsvUW8r8E4chgc1x+jBW5AEr6kvemc9c/yfZ2BiH7IN9UsQ==
X-Google-Smtp-Source: AGHT+IH6I/eKDvKDpaTxqf0Vif8bNZpwQdIBELfJDZc2RVH0AWe2ANK7oia6HYxgR/dgdtfGOGFEIb5aAcgxrAw4XbE=
X-Received: by 2002:a05:6512:acc:b0:540:20e2:da6a with SMTP id 2adb3069b0e04-54229540257mr6610984e87.30.1735241694092; Thu, 26 Dec 2024 11:34:54 -0800 (PST)
MIME-Version: 1.0
References: <CACsn0cnEJKamSSJH4-pKg1xNZ3X+__B4UwZ3P5enxP5tQ4AqzA@mail.gmail.com> <CAK2Cwb4L-KTkK96CJNwpZNiYiyMQSyH35MHNnOLEiWW+_FojZQ@mail.gmail.com> <CAFTzAXjq8AhZKKM5LC7ykFqTUAHJUD70kscrpLH-MaUFfiv_Hg@mail.gmail.com> <CAK2Cwb6Ajud45wQWvF5zDoxZSAQ2Hio55vz-rRHy=OGSvx=eXQ@mail.gmail.com> <CAFTzAXh68jH64_Pry1koyU6j-m03_kQo_Y6qfJ9BtCJVGdvWYQ@mail.gmail.com> <CAK2Cwb77n5tBh=+VD3CM4evzExDHnpdDQHQQpk7HNCcR5x8q4A@mail.gmail.com> <CH3PR13MB674707F34A0C44DDF538178AE10D2@CH3PR13MB6747.namprd13.prod.outlook.com>
In-Reply-To: <CH3PR13MB674707F34A0C44DDF538178AE10D2@CH3PR13MB6747.namprd13.prod.outlook.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 26 Dec 2024 11:34:41 -0800
Message-ID: <CAK2Cwb79M37xQeb1Cis_Mqk7507FVVoxHa6qzSvkqW+S=FucvQ@mail.gmail.com>
To: Pierce Gorman <Pierce.Gorman@numeracle.com>
Content-Type: multipart/alternative; boundary="000000000000c6a723062a317064"
Message-ID-Hash: JP47X7N6VZAEQMUCQ77NFEK7HJCL5G56
X-Message-ID-Hash: JP47X7N6VZAEQMUCQ77NFEK7HJCL5G56
X-MailFrom: thomasclinganjones@gmail.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: "peace@acm.org" <peace@acm.org>, John Wunderlich <john@wunderlich.ca>, IETF oauth WG <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: peace@acm.org
Subject: [OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/f7UIP6MDWgf0gZRk6RgVBUxLWt4>
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>

boy - this came in out-of-context.
I hope that wasn't caused by me posting to the wrong site.
I was responding to someone else about trusting the telco.
We can see cases where the phone number maps to something real.
Trusting the telcos to map the number to something real is basically
unacceptable to them.
Several countries (Estonia, India) try to register SIM cards and use the
SIM as a link to something real. That does make sense from a security
standpoint.
But that hasn't worked well in practice and now physical sims are not even
available in some countries (most phone in US)

So - what trust infrastructure "needs to exist". That's a real question
that deserves a real answer. Not clear who has the smarts and authority to
do that.

Peace ..tom jones


On Thu, Dec 26, 2024 at 10:08 AM Pierce Gorman <Pierce.Gorman@numeracle.com>
wrote:

> What mechanism(s) are you referring to that “involves trusting the telco”?
>
>
>
> Telecoms providers vary widely in their abilities (and regulatory
> regimes), and the telecoms technology continues to evolve.
>
>
>
> Voice over IP (VoIP) wasn’t really a thing 30 years ago but I will assert
> the majority of network-to-network interconnection is now dominated by
> VoIP.  And, the dominant VoIP protocol (Session Initiation Protocol aka
> SIP) was originally designed to operate peer-to-peer, and it isn’t hard to
> imagine a day when peer-to-peer will be the dominant operation instead of
> telecoms network to telecoms network.
>
>
>
> Whatever mechanism you think would be the “good thing” needs to be able to
> exist independently of existing telecoms infrastructure.
>
>
>
> Pierce
>
>
>
> CONFIDENTIAL
>
> *From:* Tom Jones <thomasclinganjones@gmail.com>
> *Sent:* Tuesday, December 24, 2024 12:34 PM
> *To:* Wayne Chang <wayne@spruceid.com>
> *Cc:* peace@acm.org; John Wunderlich <john@wunderlich.ca>; IETF oauth WG <
> oauth@ietf.org>
> *Subject:* [OAUTH-WG] Re: Alternative text for sd-jwt privacy
> considerations.
>
>
>
> *EXTERNAL EMAIL*
>
> There is always the potential to come up with a cred that will be accepted
> as enabling access to some resource.
>
> There are some proof mechanisms that state that the bearer has a cred that
> enables access.
>
> What we have not achieved is a mechanism that ties the cred to the holder
> without an ID number binding to the holder.
>
> That would be a good thing - but the only way I know involves trusting the
> telco - which we all know is a dead end.
>
> What other mechanism can bind the holder to the device w/o the telco (or
> do we just nationalize the telcos again.)
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 10:29 AM Wayne Chang <wayne@spruceid.com> wrote:
>
> No, I don’t mean an ID number. More so attributes of an entity attested by
> a non-governmental entity, and it could use privacy enhancing cryptography
> in this steelman.
>
> Best,
>
> Wayne Chang
>
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
>
>
>
> On Wed, Dec 25, 2024 at 02:17 Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
> if by ID you mean ID number - then it is a tracking number.
>
> Isn't it super obvious - why are we pretending to be privacy enabling?
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang <wayne@spruceid.com> wrote:
>
> Tom, how do you feel about private sector issued ID?
>
> Best,
>
> Wayne Chang
>
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
>
>
>
> On Wed, Dec 25, 2024 at 02:04 Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
> While Waton's statement is correct - it does not address the core problem
> with any credential that comes with an ID.
>
>
>
> All reusable IDs enable tracking.  Full Stop.
>
> All government issued ID enable tracking. Just like social insurance
> number or any other cred.
>
> So - if you want privacy - don't release the ID number.
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd <watsonbladd@gmail.com> wrote:
>
> I see that people are uncomfortable with making any mandates, and so I've
> tried to be purely descriptive in this proposal. I leave it to the WG to
> decide where to put it, but I see it as a wholesale replacement for some
> sections to emphasize clarity.
>
>
>
>  "SD-JWT conceals only the values that aren't revealed. It does not meet
> standard security notations for anonymous credentials. In particular
> Verifiers and Issuers can know when they have seen the same credential no
> matter what fields have been opened, even none of them. This behavior may
> not accord with what users naively expect or are lead to expect from UX
> interactions and lead to them make choices they would not otherwise make.
> Workarounds such as issuing multiple credentials at once and using them
> only one time can help for keeping Verifiers from linking different
> showing, but cannot work for Issuers. This issue applies to all selective
> disclosure based approaches, including mdoc. "
>
>
>
> Sincerely,
>
> Watson
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
>