Return-Path: 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 DDC4AC14F6A3 for ; Tue, 24 Dec 2024 18:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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_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=spruceid.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 l9o1xB_1-Lun for ; Tue, 24 Dec 2024 18:48:37 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 D3F6CC14F6A0 for ; Tue, 24 Dec 2024 18:48:36 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-53e3a5fa6aaso7326463e87.0 for ; Tue, 24 Dec 2024 18:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spruceid.com; s=google; t=1735094915; x=1735699715; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A3Z/8Z2AsDDKFX00kK8FmKVD7hkpmsS2hNyKxyJeUI4=; b=BtnDlPs/7cxc1+EPHN5vZ0s1ud9HD38Z8d+ffhO8eXlblqUNBT5nNCD0L9wkoCWrmE YNmt9o0yGCC0vBHPUiMDedxqPyzsVkv+Lhd5uFPxTpz/KbpPrFk+xR86DVzczsiVqjNg isgklWxc58ZRCWOh8s041YC23DPrY2cpeSo/o9wFe0A1O7b6IT1QXjmuxasICaV6XTZZ z8L7wrLM3mH4sE0GCkDMV/oEd/yIzUy33pzYuaFDi1mFOHKwO+vVQlSFZrGvNROXQK2H nGEEcmhZUb1cFMTxBgtkp2+NkdLzpn4ZqQ12VBGPBGuBOTeSM1l+uTPfpJs81EYX5Z2G 7p0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735094915; x=1735699715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A3Z/8Z2AsDDKFX00kK8FmKVD7hkpmsS2hNyKxyJeUI4=; b=DHB15wWYaMJgpnDvQcwzbwGIf2FIRA5WHhsqi40qTJZzMoLjZYe+FPTiZGp6PlSQVC oto4cZI2W8ue2N56U/lbQcAob6QZBzt1WrXxK9R7Qwt+nEjbcC6VA6pUikLr8tWNNvJD yyjLJJe+jUZCxvayCb+Obmumw+ClsOFk9ni4zOKaOSSBrSQwZCCKHnkIFC9Kf4NPxuza IufHTCNd0KKDYNgsiaRRakKbQO5sTr1PzGXIuktVr57sbimdxkOFp4P4Mn0EfRZLUmMl ez2P95mdLjw9oX9wQxrd0rcz8s5NtI2NJDbalYyS+riiBgZ0gIKqcjrhHTgVZdxY91Q1 ktag== X-Forwarded-Encrypted: i=1; AJvYcCUqb7TqCn/PocC6wx8YSYyI+vfH2k0axo6h7ifldWlp5791vtFpWPPul1aX8r/5QCjreyuFyg==@ietf.org X-Gm-Message-State: AOJu0YwHCE1uUAnjF7wWzKmGI6azD6ZqGAHxc4t0XcltXEoGQUjpAvJz Uw2oA9q8eKU+bWDMzzcAwQMeXNMt8DoiP9mgrZuo8JXkM00kpnuIwTu7pu5NDLSBVjiOaQZlOMI MX+OFZReGJCxE4a66soiv9wLsc6usKepdsMlPHw== X-Gm-Gg: ASbGncvXTvlYeE4lUSx5qHDYnoJKmtEZASgohHSwQdbfGaVJkCDmgJZZiGCUUzbql0t iMo78Ke+UndXCt+bcalj0yt6gFvUn+C6t/ZZJTw== X-Google-Smtp-Source: AGHT+IFfGj1369T9XaRT3mi6pJbhTPRf19PybD87IuYGW3OnhbZuIm2OmT61PjPkLRu913P0zmlO0AeFc4XFyIJEbEA= X-Received: by 2002:a05:6512:23a2:b0:542:1bdb:9a61 with SMTP id 2adb3069b0e04-5422946f053mr5618614e87.19.1735094915053; Tue, 24 Dec 2024 18:48:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Wayne Chang Date: Wed, 25 Dec 2024 10:48:19 +0800 Message-ID: To: peace@acm.org Content-Type: multipart/alternative; boundary="000000000000105593062a0f4425" Message-ID-Hash: KSXFPYS2LJU77QWXYZD2W4ZDELD7PTCD X-Message-ID-Hash: KSXFPYS2LJU77QWXYZD2W4ZDELD7PTCD X-MailFrom: wayne@spruceid.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: John Wunderlich , IETF oauth WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Alternative_text_for_sd-jwt_privacy_considera?= =?utf-8?q?tions=2E?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000105593062a0f4425 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hah, nationalization of telcos sounds very spicy and dangerous! I think a private sector entity (corp, non-profit, PBC, trust company, etc.) that is certified by an org like Kantara for identity provisioning with the upcoming NIST SP 800-63-4 would be interesting, and it could support a variety of cryptographic mechanisms for issuing anonymous tokens to enhance privacy, but also CMVP-friendly ones. Let's Encrypt is a good case study from the land of CAs, and you could imagine retooling ACME with oauth2 to support delegated PIV. However, we may be veering outside of the scope of the list with this topic. Best, Wayne Chang Founder & CEO | SpruceID | LinkedIn On Wed, Dec 25, 2024 at 02:34 Tom Jones wrote: > There is always the potential to come up with a cred that will be accepte= d > as enabling access to some resource. > There are some proof mechanisms that state that the bearer has a cred tha= t > 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 th= e > 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=E2=80=AFAM Wayne Chang = wrote: > >> No, I don=E2=80=99t mean an ID number. More so attributes of an entity a= ttested >> by a non-governmental entity, and it could use privacy enhancing >> cryptography in this steelman. >> >> Best, >> Wayne Chang >> Founder & CEO | SpruceID | LinkedIn >> >> >> >> On Wed, Dec 25, 2024 at 02:17 Tom Jones >> 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=E2=80=AFAM Wayne Chang wrote: >>> >>>> Tom, how do you feel about private sector issued ID? >>>> >>>> Best, >>>> Wayne Chang >>>> Founder & CEO | SpruceID | LinkedIn >>>> >>>> >>>> >>>> On Wed, Dec 25, 2024 at 02:04 Tom Jones >>>> 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=E2=80=AFAM Watson Ladd >>>>> 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 f= or 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 parti= cular >>>>>> Verifiers and Issuers can know when they have seen the same credenti= al no >>>>>> matter what fields have been opened, even none of them. This behavio= r 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 t= hem >>>>>> only one time can help for keeping Verifiers from linking different >>>>>> showing, but cannot work for Issuers. This issue applies to all sele= ctive >>>>>> 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 >> > --000000000000105593062a0f4425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hah, nationalization of telcos sounds ve= ry spicy and dangerous! I think a private sector entity (corp, non-profit, = PBC, trust company, etc.) that is certified by an org like Kantara for iden= tity provisioning with the upcoming NIST SP=C2=A0800-63-4 would be interest= ing, and it could support a variety of cryptographic mechanisms for issuing= anonymous tokens to enhance privacy, but also CMVP-friendly ones. Let'= s Encrypt is a good case study from the land of CAs, and you could imagine = retooling ACME with oauth2 to support delegated PIV. However, we may be vee= ring outside of the scope of the list with this topic.
Best,
Wayne Cha= ng
Founder & CEO | SpruceID=C2=A0| LinkedIn


On Wed, Dec 25, 2024 at 02:34 Tom Jones <thomasclinganjones@gmail= .com> wrote:
There is always the potential to come up with a c= red that will be accepted as enabling access to some resource.
Th= ere are some proof mechanisms that state that the bearer has a cred that en= ables access.
What we have not achieved is a mechanism that ties = the cred to the holder without an ID=C2=A0number binding to the holder.
That would be a good thing - but the only way I know involves trusti= ng the telco - which we all know is a dead end.
What other mechan= ism can bind the holder to the device w/o the telco (or do we just national= ize the telcos again.)

Peace ..tom= jones


On Tue, Dec 24, 2024 at 10:29=E2= =80=AFAM Wayne Chang <wayne@spruceid.com> wrote:
No, I don=E2=80=99t mean an ID nu= mber. 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=C2=A0| LinkedIn


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 obviou= s - why are we pretending to be privacy enabling?

=
Peace ..tom jones

=
On Tue= , Dec 24, 2024 at 10:15=E2=80=AFAM Wayne Chang <wayne@spruceid.com> wrote:
=
Tom, ho= w do you feel about private sector issued ID?

Best= ,
Wayne Chang
Founder & CEO | SpruceID=C2=A0| LinkedIn


On Wed, Dec 25, 2024 at 02:04 Tom Jones <thomasclinganjon= es@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.=C2=A0 Full = Stop.
All government issued ID enable tracking. Just like social = insurance number or any other=C2=A0cred.
So - if you want privacy= - don't release the ID number.

Peace ..tom jones


On Tue, Dec 24, 2024= at 6:34=E2=80=AFAM Watson Ladd <watsonbladd@gmail.com> wrote:
I see that p= eople 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 wher= e to put it, but I see it as a wholesale replacement for some sections to e= mphasize clarity.

=C2=A0"SD-JWT conceals only= the values that aren't revealed. It does not meet standard security no= tations for anonymous credentials. In particular Verifiers and Issuers can = know when they have seen the same credential no matter what fields have bee= n opened, even none of them. This behavior may not accord with what users n= aively expect or are lead to expect from UX interactions and lead to them m= ake choices they would not otherwise make. Workarounds such as issuing mult= iple 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 -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--000000000000105593062a0f4425--