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 063F4C151990 for ; Fri, 25 Oct 2024 13:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no 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 TLXHU5Wx-SF2 for ; Fri, 25 Oct 2024 13:09:36 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DC1C15198B for ; Fri, 25 Oct 2024 13:09:36 -0700 (PDT) Received: from [192.168.1.11] (unknown [90.91.46.145]) (Authenticated sender: pinkas@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id 2AE4B78032A; Fri, 25 Oct 2024 22:09:31 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------AVJYdU6fvDS00lILm39k0nGh" Message-ID: Date: Fri, 25 Oct 2024 22:09:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Watson Ladd References: Content-Language: en-GB From: Denis In-Reply-To: Message-ID-Hash: CBMQJCGCDEPQGTOODMZ3IF6I4WVSE6XD X-Message-ID-Hash: CBMQJCGCDEPQGTOODMZ3IF6I4WVSE6XD X-MailFrom: denis.ietf@free.fr 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: oauth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Second_WGLC_for_SD-JWT?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------AVJYdU6fvDS00lILm39k0nGh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Watson, 1) You wrote: if a user uses this technology to pass an age verification filter, they will end up exposing their complete identity without knowing it. When reading the current draft, I understand that your position looks correct. However, it is possible to only reveal that an End-User is over 18 without revealing his complete identity, but this can only be achieved if collusion / collaborative attacks between End-users against a Verifier can be prevented. See my comments: *33.**Section 9.5 (Key Binding), * * * ***24.**Section 5.1.2* *27.**Section 4.3.2 (Validating the Key Binding JWT)* which indicates that an additional claim is REQUIRED in that case: * -hchar: REQUIRED.This claim allows the Verifier to know specific characteristics of the Holder (holder characteristics), in particular whether some of these characteristics are able to counter Holder collaborative attacks against a Verifier. * 2) On 31/07/2024 under the topic "[OAUTH-WG] Re: We cannot trust Issuers", See: https://mailarchive.ietf.org/arch/msg/oauth/-nmcr36-4qg7NuoXhiuP1nwJonQ/ you wrote:    I've opened https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448    as a step torwads this. On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote: I would observe that any solution based on garden-variety digital signature (not something zero-knowledge like BBS / JWP) will have problems with issuer/verifier collusion.One-time tokens and batch issuance don't help.There is no such thing as SD-JWT with issuer/verifier collusion resistance.At best you could have SD-JWP. I don't think this needs to be a blocker on SD-JWT.There are use cases that don't require issuer/verifier collusion resistance.We should be clear on the security considerations and warn people away who care about issuer/verifier collusion resistance, and accelerate work on SD-JWP if that's an important property to folks. (...) There is an attempt at a discussion around unlinkablity in the privacy considerations at https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability currently.           Concrete suggestions to that text about how to better frame the risks and difficulties around Issuer/Verifier Unlinkability           (perhaps especially with respect to something like a government issuer compelling collusion from verifiers) would be welcome for consideration.  In my comment numbered 36. New Section 10.2 (Intrackability), I have purposely not used the word "unlinkability" for that case, but the word "untrackability".  A major advantage is that an Issuer *alone* cannot *track* the End-User activities.  It has been advertised that concrete suggestions "would be welcome for consideration". I have provided concrete suggestions to that text about how to better frame the risks and difficulties around this issue in my comment numbered 36. . When both the Verifier and the Issuer are forced to collaborate, e.g., upon the request from a national authority, a means to mitigate the risk is indicated. Denis > The privacy issues I have consistently raised have not been addressed > through actionable text. > > Implementers are not receiving guidance with the current version. The > actual risks are buried below a bunch of words talking around the > issue. > > I'll be very clear: if a user uses this technology to pass an age > verification filter, they will end up exposing their complete identity > without knowing it. This is an unacceptable risk, and no one disagrees > the technology poses it. Implementers will often not have the skills > or knowledge to identify this concern independently, and need > actionable guidance on how to mitigate it. We provide far more > actionable guidance on storage of credentials. > > On Fri, Oct 18, 2024 at 11:00 AM Rifaat Shekh-Yusef > wrote: >> All, >> >> This is a short second WG Last Call for the SD-JWT document after the recent update based on the feedback provided during the first WGLC >> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-13.txt >> >> Please, review this document and reply on the mailing list if you have any comments or concerns, by Oct 25th. >> >> Regards, >> Rifaat & Hannes >> _______________________________________________ >> OAuth mailing list --oauth@ietf.org >> To unsubscribe send an email tooauth-leave@ietf.org > > --------------AVJYdU6fvDS00lILm39k0nGh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Watson,

1) You wrote:
      if a user uses this technology to pass an age
      verification filter, they will end up exposing their complete identity
      without knowing it.
When reading the current draft, I understand that your position looks correct.

However, it is possible to only reveal that an End-User is over 18 without revealing his complete identity,
but this can only be achieved if collusion / collaborative attacks between End-users against a Verifier
can be prevented.

See my comments:
33. Section 9.5 (Key Binding), 

24. Section 5.1.2

27. Section 4.3.2 (Validating the Key Binding JWT)

which indicates that an additional claim is REQUIRED in that case:

      -  hchar: REQUIRED.  This claim allows the Verifier to know
         specific characteristics of the Holder (holder characteristics),
         in particular whether some of these characteristics are able to
         counter Holder collaborative attacks against a Verifier.

2) On 31/07/2024 under the topic "[OAUTH-WG] Re: We cannot trust Issuers",

See: https://mailarchive.ietf.org/arch/msg/oauth/-nmcr36-4qg7NuoXhiuP1nwJonQ/
you wrote:

   I've opened https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448
   as a step torwads this.

On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
I would observe that any solution based on garden-variety digital
signature (not something zero-knowledge like BBS / JWP) will have
problems with issuer/verifier collusion.  One-time tokens and batch
issuance don't help.  There is no such thing as SD-JWT with
issuer/verifier collusion resistance.  At best you could have SD-JWP.
 
I don't think this needs to be a blocker on SD-JWT.  There are use
cases that don't require issuer/verifier collusion resistance.  We
should be clear on the security considerations and warn people away
who care about issuer/verifier collusion resistance, and accelerate
work on SD-JWP if that's an important property to folks.

(...)

         There is an attempt at a discussion around unlinkablity in the privacy considerations at
          https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability currently.
          Concrete suggestions to that text about how to better frame the risks and difficulties around Issuer/Verifier Unlinkability
          (perhaps especially with respect to something like a government issuer compelling collusion from verifiers) would be welcome for consideration.

 In my comment numbered 36. New Section 10.2 (Intrackability), I have purposely not used the word "unlinkability" for that case, but the word "untrackability".
 A major advantage is that an Issuer *alone* cannot *track* the End-User activities.

 It has been advertised that concrete suggestions "would be welcome for consideration".
 I have provided concrete suggestions to that text about how to better frame the risks and difficulties around this issue in my comment numbered 36.
.
 When both the Verifier and the Issuer are forced to collaborate, e.g., upon the request from a national authority, a means to mitigate the risk is indicated.

Denis


The privacy issues I have consistently raised have not been addressed
through actionable text.

Implementers are not receiving guidance with the current version. The
actual risks are buried below a bunch of words talking around the
issue.

I'll be very clear: if a user uses this technology to pass an age
verification filter, they will end up exposing their complete identity
without knowing it. This is an unacceptable risk, and no one disagrees
the technology poses it. Implementers will often not have the skills
or knowledge to identify this concern independently, and need
actionable guidance on how to mitigate it. We provide far more
actionable guidance on storage of credentials.

On Fri, Oct 18, 2024 at 11:00 AM Rifaat Shekh-Yusef
<rifaat.s.ietf@gmail.com> wrote:

All,

This is a short second WG Last Call for the SD-JWT document after the recent update based on the feedback provided during the first WGLC
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-13.txt

Please, review this document and reply on the mailing list if you have any comments or concerns, by Oct 25th.

Regards,
  Rifaat & Hannes
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


--------------AVJYdU6fvDS00lILm39k0nGh--