[OAUTH-WG] Re: SD: Array Order

Orie <orie@or13.io> Mon, 29 December 2025 15:55 UTC

Return-Path: <orie@or13.io>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 48390A05FA0B for <oauth@mail2.ietf.org>; Mon, 29 Dec 2025 07:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=or13.io
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEK-vdou1vkM for <oauth@mail2.ietf.org>; Mon, 29 Dec 2025 07:55:34 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 mail2.ietf.org (Postfix) with ESMTPS id 6A9E4A05F99E for <oauth@ietf.org>; Mon, 29 Dec 2025 07:55:33 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id ada2fe7eead31-5dfd0101905so2836640137.3 for <oauth@ietf.org>; Mon, 29 Dec 2025 07:55:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=or13.io; s=google; t=1767023733; x=1767628533; 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=sRzrMPRGwG5AQJGPDToW1Q+esj5rFWi+Y5DMqKKfW4o=; b=K9U+b1+5NhXVz3BYaoGx9jHCbQ1HISi7OMKzq+4aRY1nMOHxTG1hWWZapm/XJcPy1/ 6qiFreuFjd5eLC1YIrD0p7I+PrDnJVW58vgK7qR4/Ip+8krcb2mu1A6ubmJnhoLhHI+G JsHPpdrA+yjDXOhy134TN8ABivSbOyUDXYsCoWAd3ZT1Y0USdxQ3YeSBLeQhHr+3l0KZ WguaVTYfCdpBlCCyotEAMnqt7u3BVgCA2TREMbBAh+Yq5Gh/XVSoDMqjSW7CjqC6is9x Iz877xSlreddZzULR7FrbzOtbsf3rFGMgks8N4SGr4R85P7wxk8JvdnMp1VoGt4Izhwk VB+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767023733; x=1767628533; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sRzrMPRGwG5AQJGPDToW1Q+esj5rFWi+Y5DMqKKfW4o=; b=KSDuGXmtYMgyQmm8inAgKtYvJs1MI0Kik2iCYTUY4aoxah6wsQkdJQsrz1Uy42DOAu h8bP+WirAdCzS7Ss9Eh1zdGJOLW05JvTlK1KFlIiJl4VyyalxVbrjBFK1y0GW4r6hrNJ xPBa4nG4cokbUgWfutydZBz6gC0pROcTXh9R+HLhJhAHRZk+IQC5Oz0iPZAAF21mNjQh XEqsFa0FS3WC/gYLc3WhVA+ANG4ZhZZxjYD+RcgvNMD5BXYdLt4cRPDor7qKsD+PX5lb yWGG9lUrKWnGidX9Pt3QmsHN2WcZ2K8A4v0F6Dk7yQfZ7c1SQTnas3+rSRxVYzb4fgsu EgUg==
X-Gm-Message-State: AOJu0YzczXdQUUwtfY9bn+z5MpdenvRcCdYqMm4W128rSGfqnhO7AJNX 7B2HunuKxYFFF0IDa2XLDLmGXOEVABFMbiB+XQyjodvWyJubkw0Hj1wKjmIHf6oEFNGhg2Ry+Up iBvubXX2YWFAVzWqkWip4JpRLDhRCFpCZ3/A3m71/3Q==
X-Gm-Gg: AY/fxX5/KLGkjWAgK7P0oAiHom3dEBfJfcP+aQ9Ye8G9pgDsqUFL+qPeC9OWp9q3aiA cvC+RwEZoGVCqKtbNl/kK+OqJzn7B9GQXUY+bQ2mAzbUwoHhHuMhtf6lMKMSQZKXRPuWJu/mVji E8VH3vQFV4VsSBBNv87hERl9q12eeq8xTmvs84GHb9yxK50sga1JCqkMC9i/lMwCGCvJbnrVqN1 +XDvkXNTPUH7S3bctAELV/f1bVPED1qpbEF+x3zASSlSDSqvfqhP8dNXmLvUCBK6I8qKUetix6H 4B8aAFPEHU/0eMlD+I2qloO/rUo62A==
X-Google-Smtp-Source: AGHT+IFstTrTLEMLE7Eyt203HxqbeMwj8qtWVZ4HHUkTBJpFU2OOE5rNBImwqqV4R/ZsurLAKBnjyypQTN1AoH8VJaE=
X-Received: by 2002:a05:6102:152a:b0:5e5:6360:1f5c with SMTP id ada2fe7eead31-5eb1a848e8amr7979027137.42.1767023732831; Mon, 29 Dec 2025 07:55:32 -0800 (PST)
MIME-Version: 1.0
References: <CAMzqgoxFSW2GsZ=VckQyv3+=3yPReP6xWJPyZmZAtXDiQFiNTA@mail.gmail.com> <CACsn0c=SZ9ha6FCRWdQjFuABMyJehTU5gea2B26ObYFPTrqGoQ@mail.gmail.com>
In-Reply-To: <CACsn0c=SZ9ha6FCRWdQjFuABMyJehTU5gea2B26ObYFPTrqGoQ@mail.gmail.com>
From: Orie <orie@or13.io>
Date: Mon, 29 Dec 2025 09:55:22 -0600
X-Gm-Features: AQt7F2oQ3eZ-uRqIdx6B1rZdBrn5iIix-Opl-5BUQugoTeTEy30KQeExUd4_kD4
Message-ID: <CAMzqgowwqW3hrt8jeAbRQugnOYvdJO_KGmAPmQHc84_bM0KFRg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e7c9c706471945e5"
Message-ID-Hash: NCOJJ5LSVSXGMYS7S3ZFK7WGT5MTRDOL
X-Message-ID-Hash: NCOJJ5LSVSXGMYS7S3ZFK7WGT5MTRDOL
X-MailFrom: orie@or13.io
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 WG <oauth@ietf.org>, spice@ietf.org, Rohan Mahy <rohan.mahy@gmail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: SD: Array Order
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EKNhobXc99pe8n09CZMN2mI9L3M>
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>

You are correct, the verifier does know the array length, and index of each
redaction.

When map keys are redacted, they can be removed from the claimset without
loss, since map (object) key order is not a thing in JSON.

We are talking about the "verified claim set", which is the result of
performing the verification step, which substitutes the disclosed claims
for the redacted ones, and removes the redaction place holders.
The result of this process should be a JWT / CWT claimset that is
indistinguishable from a traditional JWT / CWT claimset, so that downstream
claims processors do not need to understand SD JWT / SD CWT.

https://datatracker.ietf.org/doc/html/rfc9901#section-7.1-4.3.2.4

I guess OAuth suggested removing the array elements and not replacing them
as null... So we should take the same approach.

Sigh.... That's what I get for asking AI to help me read the SD-JWT RFC.

Regards,

OS


On Mon, Dec 29, 2025 at 9:44 AM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Mon, Dec 29, 2025, 10:04 AM Orie <orie@or13.io> wrote:
> >
> > Hi,
> >
> > As we've implemented sd-cwt, we've encountered the same challenges
> regarding redaction and array order that sd-jwt encountered.
> >
> > ## Consider:
> >
> > my array = [ "hello", 123, true ]
> >
> > When redacted, this becomes:
> >
> > my array = [ "hello", REDACTED, true ]
> >
> > When presented to downstream verification services, should they see:
> >
> > ### Case 1
> >
> > my array = [ "hello", true ]
> >
> > ### Case 2
> >
> > my array = [ "hello", null, true ]
> >
> > ## Reasoning
> >
> > We're currently planning to recommend case 1 as the safe default,
> because if order conveys meaning, it would be better to just redact the
> entire array, since redacting individual elements leaks information, by
> relative positioning.
>
> I'm a bit confused. As I understood it, the length of the array and
> ordering is always exposed to the verifier in the commitments that
> then get hashed together to verify the signature. As a result there is
> no way to selectively disclose in a way that only shows the number of
> elements and hides which indexes they are. I'm also not sure if there
> was, that this would still be an array. Is this just for the output to
> the program after verification, or does this affect the shape of the
> disclosures?
>
> >
> > The decision on how to handle this case seems possibly data model
> specific, so we propose to recommend a safe default (change array size),
> but describe the replace with nulls procedure for implementations that
> process data models where order must be preserved.
> >
> > Feedback is welcome.
> >
> > Regards,
> >
> > OS
> >
> > _______________________________________________
> > OAuth mailing list -- oauth@ietf.org
> > To unsubscribe send an email to oauth-leave@ietf.org
>