Withdraw `application/vc+ld+json+jwt` and `application/vp+ld+json+jwt`

[OR13]

Reasoning.

1. "alg: none" is legal per JWT, in +sd-jwt it's not legal "MUST NOT be none or an identifier for a symmetric algorithm (MAC)."
2. +sd-jwt supports all the signature algorithms, making support for +jwt redundant.
3. One less media type to get wrong.
4. (downside) no MAC based signatures for "W3C Verifiable Credentials".

This would simplify a lot of the spec text, and leave us with 1 envelope format for JSON (+sd-jwt), and one for CBOR (+cose).

This would leave only:

• application/vc+ld+json+sd-jwt

• application/vp+ld+json+sd-jwt

• application/vc+ld+json+cose

• application/vp+ld+json+cose

[brentzundel]

This makes good sense to me and also matches our implementation afaict.

[mprorock]

makes a lot of sense, and likewise matches our implementation

[dwaite]

Is there a degenerative form of SD-JWT for issuers who do not want selective disclosure?

[OR13]

@dwaite afaik, yes, you get a JWT with an extra ~ (not a JWT per the media type serialization rules) in the case where you choose not to make any claims selective disclosable.

[msporny]

you get a JWT with an extra ~

That's not a JWT... it will fail processing w/ a regular JWT library, no?

[OR13]

@msporny it will fail the serialization requirements from https://www.iana.org/assignments/media-types/application/jwt

[Sakurann]

+1 to this approach.

when SD not needed, remove ~ and then use a JWT lib. <- fully legal in sd-jwt spec

[alenhorvat]

Either ~ is removed (so 0 ~) or 2 ~~ are needed in the sd-jwt (1st separates the disclosures, 2nd the "key binding vc").

In the current proposal in the limit of 0 disclosures we end up with 2 different encodings for the same content.

[selfissued]

This is addressed by PR #149

[OR13]

we did this.