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 <[email protected]> wrote:

> On Mon, Dec 29, 2025, 10:04 AM Orie <[email protected]> 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to