I appreciate the explanations!
On 4/3/25 12:56, Daniel Fett wrote:
Hi Chad,
Thank you for your review of the specification! My comments below:
Am 03.04.25 um 08:57 schrieb Chad Parry:
> The ellipsis name was introduced in version 5 of the specification,
> but the "_sd" name was retained. If an ellipsis is deemed more
> readable (section 4.2.4.2, and I agree it is), then why not use them
> instead of "_sd"? If the placeholder name needs to begin with an
> underscore, then presumably the existing ellipses usages are unsafe
> and need to be changed. In that case, "_..." would be fine too, as
> long as both object and array placeholders use a consistent name. In
> the payload above, I've used ellipses throughout.
The "_sd" with the underscore was chosen (long before ...) to avoid
potential conflicts with existing keys in the structure. The underscore
has no special meaning, but the hope is that it makes it visually clear
that this key has a special role.
The "..." was chosen intentionally distinct from "_sd" to ensure that
even when only parsing the structure without looking at the disclosures,
the type of contents that can be expected in an object can be derived.
Makes sense. I would have tried to make the two keys similar since they
come from the same spec, but your argument is defensible. The current
format is a vast improvement over what I saw in the version 1 specification.
> In the specification, the value of the _sd property is always an array
> while the ... property is always a string. It would be more consistent
> if both could always be arrays. If brevity is desired, then a single
> digest can be treated as if it were an array of one. In my example,
> I've used arrays only when there are multiple digests.
This creates polymorphism, which is usually not well-received by
implementers, for good reasons.
Sure, that also makes sense.
> Claim birthdate Value:
> * SHA-256 Hash: JL6Qz1obsng36vklAZGvir9NgVV2XsQa-1h4s7oHTrE
> * Disclosure: WyJXOC1KSmpuU0ZPN1dlVUJ1UmZWQ1N3IiwgIjE5NDAtMDEtMDEiXQ
> * Contents: ["W8-JJjnSFO7WeUBuRfVCSw", "1940-01-01"]
>
> Continuing in the same vein, the disclosed value could be a primitive
> instead of an object. The payload has non-selectively-disclosed a
> claim with the name "birthdate" but has not revealed whether it is a
> string or number, much less its value. This makes the substitution
> rules for property values the same as for array elements, which could
> already hide the type. It would also relax the constraints described
> in section 9.6, "Blinding Claim Names."
Correct me if I'm wrong, but the same considerations would still apply.
There would just be an additional option to always disclose the claim name.
>
> Array Entry:
> * SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
> * Disclosure: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
> * Contents: ["lklxF5jMYlGTPUovMNIvCA", "US"]
>
> Array entries in this example look exactly the same as the
> specification already describes. However, now they fit into a more
> robust pattern, where all disclosures consist of a salt and a value.
> Substitution rules would work the same for object properties
> (name/value pairs), array elements, and property values:
> 1. The disclosed value replaces whichever target object contained the
> ellipsis.
> 2. Except that if the target object contains other claims or digests,
> then the disclosed value must be an object type and its claims get
> merged into the target object instead of replacing it.
As above, the price of this is that the structure itself is not
self-explanatory anymore. In your example, without looking at the
disclosures, I can't tell if nationalities is an array of strings or an
array of objects.
I had thought that it was a feature to hide the shape of undisclosed
elements. Maybe I misunderstood the goals. Correct me if I'm wrong, but
in the current specification, it's already impossible to tell whether
"nationalities" is an array of strings or an array of objects (in
sections 4.2.6 and 5). IMHO, a self-explanatory structure is both
undesirable and unachievable.
As long as you support an embedding that has the format {"...":
"<digest>"}, why restrict it to array elements? In section 7.1, step
3.2.2, the instructions say, "Find all array elements that are objects
with one key, that key being ... and referring to a string." It would be
simpler to explain and implement, "Find all objects with one key, that
key being ... and referring to a string."
You characterized this as "an additional option to always disclose the
claim name." That's true, but I don't think of it as adding a feature; I
think of it as removing an artificial restriction that doesn't appear
beneficial.
This change would be completely backward compatible for existing Issuers
and forward compatible for Verifiers.
- Consistency alone won't buy you anything. With the current structure,
the processing of the SD-JWT is very clear, simple, and somewhat robust,
as a three-valued disclosure would not be valid for an array entry and a
two-valued disclosure would not be valid for an object key. That's a
feature, not a bug, in my book. We have clearly separated explanations
and code paths for _sd and ...; I found that easy to implement and we
have not received any implementer feedback to the contrary.
To be sure, the current instructions are clearly not a burden to
implementers. The specification is well written.
Last but not least, I'd like to highlight that we have *many*
implementations for SD-JWT out there, so many in fact that I can't list
them all. We have 17 libraries named in our repository, and there are
countless Issuers, Wallets and Verifiers that already use SD-JWT (for
example, in the EU Digitial Identity Large-Scale Pilots). Unless there
are very good reasons, they would certainly not appreciate us breaking
the format at this stage.
Yes, it's an impressive list of early adopters. I realized I started
this discussion far too late even before I knew about the large-scale
pilots. Thanks for taking the time anyway.
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
