Make SD-JWT(0) and JWT the same

[bifurcation]

An SD-JWT with zero disclosures and no key binding is the same as a JWT -- you can't undo any of the selective disclosures, so you have to take the claims as they are. But with the current document, the two cases are syntactically different: SD-JWT(0) has a ~ character at the end, and a plain JWT doesn't.

This mismatch is unfortunate for a couple of reasons. It means that if you're taking one of these objects between SD-aware and non-SD-aware contexts, you have to have a mapping layer that adds and removes the ~. And it makes it impossible to use the key binding feature as-is with a plain JWT, because the key binding feature assumes that the thing being bound ends with the ~ separator.

I would suggest refactoring as follows:

1. Define the format of the "SD-JWT without key binding" thing to be simply IssuerJWT~disclosure~...~disclosure (no final ~)
2. Define the format of an [SD-]JWT with key binding to be JWT~KBJWT (with the intermediate ~, which is absent today)

This aligns well with the distinction proposed in #374.

[bc-pi]

We want to allow for https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ to consistently convey JWTs both with and without selectively disclosable content. Which is does currently with the trailing tilde.

[Sakurann]

I think there are four cases here:

1. SD-JWT without selective disclosure and without KB JWT: JWT~ or JWT
2. SD-JWT without selective disclosure and with KB JWT (in scope of SD-JWT VC): JWT~KBJWT
3. SD-JWT with selective disclosure and without KB JWT (in scope for SD-JWT VC): IssuerJWT~Disclosure...Disclosure~ or IssuerJWT~Disclosure...Disclosure
4. SD-JWT with selective disclosure and with KB JWT (in scope for SD-JWT VC): IssuerJWT~Disclosure~...~KBJWT

For point 2 in my list above (Richard's point 2), there is a related issue in sd-jwt vc spec so it should be clarified.

For points 1 and 3 in my list above (Richard's point 1), this is where suggestion not to end with ~ diverges from SD-JWT/SD-JWT VC approaches. when there is selective disclosure (point 3), in addition to what Brian said, there are ~s between disclosures anyway, so I do not see the advantage in processing whether there is a ~ in the end or not. so even if there is no selective disclosure (point 1), for the consistency/interop sake, having JWT~ does sound better. But I do agree with Richard that when there is no selective disclosure, it is just a JWT, so the i think it is up to the use-case and implementations to do JWT~ when they think that that JWT may enter verifiable credential ecosystem where JWTs with selective disclosure are also used and not something for the standard to dictate..

[danielfett]

For the first case, I think distinguishing an SD-JWT without disclosures and KB-JWT (JWT~) from a pure JWT (JWT) is an important feature: It allows a receiver to always unambiguously distinguish the two cases and tell which processing is required. (It's a bad idea to put an SD-JWT into a JWT processor as it may contain SD-JWT specific structures that should be removed before further processing.)

For case three, having the last ~ enables us to distinguish between a presentation with a KB-JWT and a presentation without a KB-JWT without introspecting the last element.

[Sakurann]

It does not make sense to always mandating disclosing something, or always mandating KB JWT, so SD-JWT without selective disclosure and without KB JWT is simply a unique case of SD-JWT, so SD-JWT~ makes more sense and as Daniel argues, what came out of and is intended to be consumed by SD-JWT library, it is better from a developer perspective to have ~ and not be consumable by a vanilla JWT library.

[bifurcation]

@Sakurann I'm a little puzzled that you think the extra ~ is better for developer experience. An SD-JWT without disclosures is literally just a JWT where some of the claims have nonsense values.

But I guess you could argue that that's a reason that an SD-JWT(0) should still not be processed by a vanilla JWT library -- because an SD-JWT will recognize the SD claim values as nonsense, as opposed to trying to interpret them.

Under that theory, I'm OK with closing this.

[danielfett]

But I guess you could argue that that's a reason that an SD-JWT(0) should still not be processed by a vanilla JWT library -- because an SD-JWT will recognize the SD claim values as nonsense, as opposed to trying to interpret them.

That is exactly the point why we decided to keep the current form.