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

[Brian Campbell <[e-mail]>]

As someone with some experience in this space, I believe it's reasonable to
acknowledge that the layering within JWS/JWT is not perfectly clean.
Consequently, reasonable sounding arguments can be made for placing the
"_sd_hash" either in the header or the payload. Ultimately, this is
somewhat subjective, and neither approach is definitively 'correct.' Given
that, it's difficult to see a compelling reason for change, particularly at
this stage in the process.

Similarly, naming conventions for claims are inherently subjective, perhaps
even more so. As such, I see little justification for altering them at this
point based on personal preferences or aesthetic considerations.


On Sun, Sep 22, 2024 at 8: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]
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._