Closed msporny closed 5 months ago
I already raised a similar issue to this (#191). My proposal is to keep the focus on SD-JWT, now that the work has advanced from vanilla JOSE securing to securing with selectively disclosure. Many implementations are migrating from vanilla JOSE to SD-JWT. I think it will be very widely adopted. Consequently I believe we need to improve the descriptions of using SD-JWT. I have raised PRs #212, #213 and #215 as a start. We will also need similar text for securing VPs in Example 2 in section 3.1.2.
As to support for COSE securing, I cannot comment on the support that there is for this.
The working group already made a deliberate decision to remove pure JWS signing in favor of SD-JWT signing to remove choices. SD-JWT has a superset of JWT functionality. If no claims are selectively disclosable they are equivalent. (Yes, there's a trailing ~ added to the JWT as a marker that the data structure is an SD-JWT, but once that's removed, it can be processed by a standard JWT library.)
I'm open to discussing re-adding JWS signing, but I view that as a fallback we'll pursue in the future only if something goes terribly wrong with SD-JWT.
If no claims are selectively disclosable they are equivalent.
No, they are not. The SD-JWT really needs to stop saying this. Yes, you can easily convert from one format to the other, but to say that they're equivalent is just simply not true and the JOSE group will continue to be reminded of this point until the way SD-JWT is being presented to the world is changed to reflect the fact that you can't just pick up a standard JWT library and start processing SD-JWTs, primarily because that standard JWT library falls apart the second an entity does a selective disclosure, which you would expect every implementation to support given that you are using a selectively disclosable format.
SD-JWT is not JWT and MUST NOT be presented as such, even in prose.
I will note that there are production deployments of VC-JWT v1.1 and some of those organizations are probably expecting standard JWTs to continue to be supported. There are also ecosystems that don't need SD-JWT and would rather continue to use JWTs.
If the specification is not going to specify VCs protected by standard JWTs, it needs to clearly document why and that it MUST NOT be done to focus on SD-JWT.
I'm open to discussing re-adding JWS signing, but I view that as a fallback we'll pursue in the future only if something goes terribly wrong with SD-JWT.
A decision needs to be made one way or the other. I'll note that not all VC use cases need SD-JWT and many are negatively impacted by the complexity of SD-JWT. If a system receives an SD-JWT, it cannot presume that there will be no selective disclosures attempted, nor can it expect to use "off the shelf" JWT tooling and get away with it.
I agree we should be explicit to either support all of JOSE or just SD-JWT before proceeding.
The issue was discussed in a meeting on 2024-01-09
List of resolutions:
Discussed today on the editors call we will add a section similar to JOSE/COSE sections for SD-JWT, may be under the JOSE section.
The current specification does not support JWT-secured VCs and focuses on SD-JWT instead. This is concerning for two reasons:
At a minimum, the specification should elaborate on how a VC can be secured using a JWT.
Section 3.1.1 adds to the confusion by referencing RFC7515 (JSON Web Signatures), but then specifies the media type as
vc+ld+json+sd-jwt
. This is confusing because RFC7515 does not contain any information on how to secure anything using SD-JWT.