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 5EB00C18DB93 for ; Tue, 24 Sep 2024 04:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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] 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 lcJ1kc78lZ3K for ; Tue, 24 Sep 2024 04:34:03 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 E353AC180B42 for ; Tue, 24 Sep 2024 04:34:03 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-e1a80979028so5307505276.1 for ; Tue, 24 Sep 2024 04:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727177643; x=1727782443; 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=TaXTqIX3yfySKoQkGQWmXULEAvnhM36BQkhYsc6Kc4c=; b=mo/L7k7tIFf0oOFBDbF6pfG8gSZ7t0rBexWa4sO5dl3FpODhypmrHHZPMliUyAgKB7 H8qRyx/VO93tUcTNBSrDkg2K50u55+SwwDUXB+LzDlQHuNXnmFzVK+0DPZA4aoUeNFTz wDgbSi/7ydV6hfQz3ax9E/5KfGTWbGx8h7PWup4Bw7jr1entY9ceE3JgyCIbKaJfwXla cWBlTzbreXm8mInN8lMj9M/pjkA2J9qBnkzksQsGkvRx1gIY5rYTbeGZPyGyYBFL5stX AtpfXxe4Nru2pItmFODQpiQOLjrKM3vzNJ9sD4azGg6GGTznzj251JDztvHNbJBFNvxB x1Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727177643; x=1727782443; 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=TaXTqIX3yfySKoQkGQWmXULEAvnhM36BQkhYsc6Kc4c=; b=t+doBp+C3Yl4YQRRtMy9fD2cBVahDpZ6NJBa/jOvYellR7izA/itjH+ajdde9tNijz j8eC/r972uXFtZghZlmki4hk6ItBd/deIvdnZxAWPtFBQ45fKwU2Eq+uNkiYAmIvzbcn 6xGBh0GcRkVT8Vmi1Gl5UyB42tTzrXb/7NCjhGwSl83T7PSn6t+GJiLVaIKnb/ghqWqs MM3pVSioFIIWiByLI5pFDXUZWSE/8urWiaYTAjdo09vR7BZMGTaDBNojWK3v2rzb7Mdz 1vhoQ1Eygn+mz52htlQtr1rDplD9pjelSY03PgnI3vw7suW7YmAyYTdx8U8Q3PtMLTHz wfRA== X-Gm-Message-State: AOJu0YyvZgCa7f6s0Ha7kYQg6G62q6w1ioDfcGZEmSRA+wsgBYh0nOWq bqU+fpQ01mOOURfHEsmKKZiq2OZMFpxu3/3oLLVkiVYVW2HUIDA+6xHOdoM81JlVsmA7bjvvdEC pDAdl708amRoms4IAisJqnircrz0= X-Google-Smtp-Source: AGHT+IFk58uc31P0Th6Oxc60jIQnh8Fr8PbZx4Vb5Boyz32zfHhpV1+iPitSSQ6fTpX5tWD8r2kuqYckwYZRPYcFkyU= X-Received: by 2002:a05:6902:270a:b0:e1a:ae94:ee5c with SMTP id 3f1490d57ef6-e2250c3d5ebmr11415126276.18.1727177642960; Tue, 24 Sep 2024 04:34:02 -0700 (PDT) MIME-Version: 1.0 References: <51d9e2b2-e766-4eea-8b31-a0ae5b2cfae4@danielfett.de> <99733e6b-e5aa-4a94-8f4d-bb994628fd74@danielfett.de> In-Reply-To: <99733e6b-e5aa-4a94-8f4d-bb994628fd74@danielfett.de> From: Dick Hardt Date: Tue, 24 Sep 2024 12:33:26 +0100 Message-ID: To: Daniel Fett Content-Type: multipart/alternative; boundary="000000000000df6f700622dbe127" Message-ID-Hash: TNRJJSO6COZY27W3MJYJ7PI5HAHI55WV X-Message-ID-Hash: TNRJJSO6COZY27W3MJYJ7PI5HAHI55WV X-MailFrom: dick.hardt@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: oauth@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Reply-To: Dick.Hardt@gmail.com Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_SD-JWT_and_Unlinkability?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000df6f700622dbe127 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Where is the guidance going to live for the issuer and holder for batch issuance? Just as there is guidance on salt entropy, digest algorithms etc. I suggest it be clear to implementers what the best practice is. For example, is each credential one time use? Does the holder need to track which verifiers received which credentials? The objective is defeated if the same verifier receives all the different credentials. A likely situation where the user regularly uses a credential for access. As mentioned in another thread, I consider batch issuance a hack, and that it will likely be defeated *if* there is value to an attacker in correlating the user across apps. /Dick On Tue, Sep 24, 2024 at 12:07=E2=80=AFPM Daniel Fett wrote: > A few points: > > * Batch credential issuing is completely transparent to the user. > > * The selection is done by the Wallet, before presentation. > > * It doesn't need to be random, the Wallet can just select the next > credential. > > -Daniel > Am 21.09.24 um 17:53 schrieb Tom Jones: > > that doesn't answer the question about users randomly selecting some to > store and some to reject. This seems to me like user private information= . > As is most of the feedback to the issuer from the wallet. > Peace ..tom jones > > > On Sat, Sep 21, 2024 at 7:30=E2=80=AFAM Daniel Fett 40danielfett.de@dmarc.ietf.org> wrote: > >> Hi Dick, >> >> Batch credential (not claims) issuing has become the default approach to >> circumvent the inherent limitations of salted-hash-based credentials >> formats. This was neither invented by us, nor is it unreasonable to ask >> implementers to do it. Protocols such as OpenID4VCI support it. >> >> -Daniel >> Am 21.09.24 um 06:42 schrieb Dick Hardt: >> >> Is it really going to be practical to batch issue claims, and have the >> holder randomly choose between them on presentation? >> >> As an implementer, what is the right number of claims to be in a batch? >> >> This section of the draft reads as a hack to add a new capability >> (unlinkability) to a mechanism that did not have that as a design object= ive. >> >> This is going to be like the "alg":"null" for SD-JWT. :-) >> >> >> _______________________________________________ >> 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 > --000000000000df6f700622dbe127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Where is the guidance going to live for the issuer and hol= der for batch issuance?

Just as there is guidance on sal= t entropy, digest algorithms=C2=A0etc. I suggest it be clear to implementer= s what the best practice is.=C2=A0=C2=A0

For example= , is each credential one time use? Does the holder need to track which veri= fiers received which credentials?

The objective is defeated if the s= ame verifier receives all the different credentials. A likely=C2=A0situatio= n where the user regularly uses a credential for access.
As mentioned in another thread, I consider batch=C2=A0issuance= a hack, and that it will likely be defeated *if* there is value to an atta= cker in correlating the user across apps.=C2=A0

/D= ick

On Tue, Sep 24, 2024 at 12:07=E2=80=AFPM Daniel Fett <mail=3D40danielfett.de@dmarc.ietf.= org> wrote:
=20 =20 =20

A few points:

* Batch credential issuing is completely transparent to the user.=C2=A0

* The selection is done by the Wallet, before presentation.

* It doesn't need to be random, the Wallet can just select the next credential.

-Daniel

Am 21.09.24 um 17:53 schrieb Tom Jones:
=20
that doesn't answer the question about users randomly selecting some to store and some to reject.=C2=A0 This see= ms to me like user private information.
As is most of the feedback to the issuer from the wallet.
Peace ..tom jones


On Sat, Sep 21, 2024 at 7:30=E2=80=AFAM Daniel Fett <mail=3D40danielfett.de@dmarc.ietf.org> wrote:

Hi Dick,

Batch credential (not claims) issuing has become the default approach to circumvent the inherent limitations of salted-hash-based credentials formats. This was neither invented by us, nor is it unreasonable to ask implementers to do it. Protocols such as OpenID4VCI support it.

-Daniel

Am 21.09.24 um 06:42 schrieb Dick Hardt:
Is it really going to be practical to batch issue claims, and have the holder randomly choose between them on presentation?

As an implementer, what is the right number of claims to be in a batch?

This section of the draft reads as a hack to add a new capability (unlinkability) to a mechanism that did=C2=A0not have that as a design objective.

This is going to be like the "alg":"nul= l" for SD-JWT. :-)


_______________________________________________
OAuth mailing list -- oauth@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
--000000000000df6f700622dbe127--