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 <dick.ha...@gmail.com> 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 <michael_b_jo...@hotmail.com> > 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 <dick.ha...@gmail.com> >> *Sent:* Saturday, September 21, 2024 9:16 AM >> *To:* Daniel Fett <m...@danielfett.de> >> *Cc:* oauth@ietf.org; krist...@sfc.keio.ac.jp >> *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 -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
