[OAUTH-WG] Re: Leading underscores in SD-JWT Claim Names (was SD-JWT architecture feedback)

[Rohan Mahy <[e-mail]>]

Dick,
I would like to point out that `_sd` won't just be present at the top
level. It could be present arbitrarily deep in the object hierarchy. There
is an excellent chance that some hierarchy of JWTs already has an `sd`
claim (claims deeper than the top level are not currently covered by an
IANA registry), or a `digests` claim for that matter. Using an underscore
(meaning it is a claim about a claim), I think we are much more solid
ground with respect to a claim that can appear almost anywhere in a JWT.

Regarding `_sd_hash`, I can see your point about this being something that
feels like a (protected) header. As an implementer, I don't really care
either way. It is the same amount of work either way.
Thanks,
-rohan

On Sun, Sep 22, 2024 at 7:16 AM Dick Hardt <[e-mail]> wrote:

> I have a few points here as well:
>
> 1) the hash algorithm should be in the header. It is not a claim. It
> describes how to process the rest of the text in the token. People parse
> the header to learn what to do with the rest of the string. That was a key
> decision in this format.
>
> 2) underscores typically signal that something is an internal / off limits
> value. The digests are a claim in the payload that are expected to be
> operated on.
>
> 3) related to that, calling the digests "digests" would be more meaningful
> that "_sd" -- as that is what they are
>
> Just because there are other claims with _ does not mean they are
> intuitive to an implementer in this case. Daniel did not rationalize the
> use of underscore because other claims that are meta data used an
> underscore.
>
> Per my other note, I'm just giving my feedback as a community member. Zero
> interest in winning an argument.
>
> On Sat, Sep 21, 2024 at 9:06 PM Michael Jones <[e-mail]>
> wrote:
>
>> SD-JWT is following an existing OAuth (and OpenID) convention by
>> including an underscore prefix in the names of claims about claims.  You’ll
>> find that _claim_names and _claim_sources are registered at
>> https://www.iana.org/assignments/jwt/jwt.xhtml, which are both claims
>> about claims, rather than claims whose values are used in the usual way.
>>   These are currently the only claims with leading underscores registered.
>>
>>
>>
>> Therefore, I believe SD-JWT is on solid ground creating and registering
>> the names _sd and _sd_alg as other claims about claims.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Dick Hardt <[e-mail]>
>> *Sent:* Saturday, September 21, 2024 9:16 AM
>> *To:* Daniel Fett <[e-mail]>
>> *Cc:* [e-mail]; [e-mail]
>> *Subject:* [OAUTH-WG] Re: SD-JWT architecture feedback
>>
>>
>>
>> …
>>
>>
>>
>>
>>
>> *Claim Names*
>>
>> Why do the claims start with '_'? Why not just 'sd' and 'sda'? Why is
>> '_sd_alg' in the payload and not in the header?
>>
>> While the underscore doesn't officially have any special meaning, adding
>> it reduces the chance for collisions with existing claims and makes the
>> SD-JWT-related claims sort nicely. All SD-related claims are in the
>> payload, that's why we put _sd_alg there as well.
>>
>> Do you have data that shows it will reduce collisions? I have seen many
>> implementations that created their own claims that start with _ to reduce
>> collisions with the same rationale!
>>
>>
>>
>>  There is an IANA registry for claim names to avoid collisions.
>>
>>
>>
>> The _ reminds me of internal C variables that others were not supposed to
>> use, but eventually did.
>>
>>
>>
>> _sd_alg is NOT a claim. It is a signal for which algorithm to use and
>> should be in the header.
>>
>>
>>
>> I'm unclear on the sorting advantage. They would sort together if they
>> started with sd as well.
>>
>>
>>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>