Make project sd-jwt-vc compliant

[cre8]

This PR makes the library compliant to sd-jwt-vc since sd-jwt only defines the protocol of the selective disclosure approach.

Since the sd-jwt-vc is the only spec that seems to be stable engouth to be used with sd-jwt, I changed the core values.

First thoughts to split it up were aborted since the integration of a W3C-VC-DM is not standardized and could lead to massive interop problems.

Open questions before accepting this:

Required types

The sd-jwt-vc required the following values to be specified in a credential

• iss: reference to the issuer.
• iat: issuance data
• vct: reference to the schema of the credential

I decided to pass them together with the claims in the issue function like:

const credential = await sdjwt.issue(
    {
      iss: 'Issuer',
      iat: new Date().getTime(),
      vct: 'https://example.com',
      ...claims,
    },
    disclosureFrame,
  );

In case the issuer is a did, the iss has to be the url referencing the key like did:web:exmaple.com#key1.
Issuance date should not be automatically calculated by the SDK since an issuer could have an intention to set it to another value (I don't see a reason for this, but doing so we are not limiting him).
I would also suggest to pass the issuer value during the issuance process and not via the init of the SDJWT Instance. The kid field will also not be updated intern, the user is able to pass it in the third parameter when issuing.

VCT should define the type, see https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html#name-verifiable-credential-type- This seems to be required, but we are not able to set this by the SDK.

Renaming

I did not rename classes like SDJwtInstance since they do not include any logic that is specific for the SD-JWT-VC usage, we can rename this, but it would be a breaking change

Signed-off-by: Mirko Mollik [email protected]

[codecov]

Codecov Report

Attention: Patch coverage is 97.40260% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 96.10%. Comparing base (2d8206e) to head (2f7c125).

Files	Patch %	Lines
packages/sd-jwt-vc/src/index.ts	96.36%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             next     #114      +/-   ##
==========================================
+ Coverage   95.54%   96.10%   +0.56%     
==========================================
  Files          21       22       +1     
  Lines        1705     1771      +66     
  Branches      246      251       +5     
==========================================
+ Hits         1629     1702      +73     
+ Misses         72       69       -3     
+ Partials        4        0       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lukasjhan]

@cre8 Looking at the code, I thought about it some more.
I think I like our first approach better which is separate sd-jwt and sd-jwt-vc.
The sd-jwt-vc standard is still at version 1, and more uses of sd-jwt may come out in the future.
I think it's too early to make a decision to merge. Approaching cautiously, expanding sd-jwt-vc class from sd-jwt would be a safe job.

[cre8]

@cre8 Looking at the code, I thought about it some more. I think I like our first approach better which is separate sd-jwt and sd-jwt-vc. The sd-jwt-vc standard is still at version 1, and more uses of sd-jwt may come out in the future. I think it's too early to make a decision to merge. Approaching cautiously, expanding sd-jwt-vc class from sd-jwt would be a safe job.

I first thought the same,
but since we do not know how other approaches will look like, it's difficult to build a generalised layer. So I would suggest to just go with this since it's just a small adjustment and later we can optimize it

[berendsliedrecht]

I would also strongly recommend to make the sd-jwt-vc a separate package. sd-jwt by itself, without the vc restrictions, is still very useful and not every use case requires the
additional restrictions. Extracting it into separate should not be that much effort and it would greatly improve the usability of this library. And also, easier to extend upon in the future with different formats.

[cre8]

@berendsliedrecht good point, I add the other package

[cre8]

@lukasjhan @berendsliedrecht added a new package
New:

• Implementations need to pass the head type like sd-jwt-vc
• Implement the "always disclosed" function

I copied the e2e test from sd-jwt and modified the input so it's compliant.

[lukasjhan]

Is there a way to just use it as a class instead of making sdjwtInstance an abstract class?

[cre8]

Is there a way to just use it as a class instead of making sdjwtInstance an abstract class?

Like described above, sd-jwt:
"This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims." https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html
So this spec defines the mechanism

This spec for the sd-jwt-vc defines the usage of the sd-jwt inside a verifiable credential: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html

So to be compliant to the spec you can not use only sd-jwt as the credential format, you need an implementation of the class to specify the header type

[lukasjhan]

@cre8 The big change is not being able to use sd-jwt raw. I think the rest is okay.
If I were to decide on my own, I think I would approve this PR. :)

@berendsliedrecht Can you tell me what you think?

btw you need to fix the examples/core-example. They use raw sdjwtInstance

[cre8]

@cre8 The big change is not being able to use sd-jwt raw. I think the rest is okay. If I were to decide on my own, I think I would approve this PR. :)

@berendsliedrecht Can you tell me what you think?

btw you need to fix the examples/core-example. They use raw sdjwtInstance

I wouldn't call it "big change" or "breaking change" since we moved back to version 0.x that allows to be unstable. Also we are getting compliant to the spec we were not in the first place.

I moved the examples from core to sd-jwt-vc and made a node in the packages about this.

[lukasjhan]

@cre8 Good. Examples are all good :)

[berendsliedrecht]

So to be compliant to the spec you can not use only sd-jwt as the credential format, you need an implementation of the class to specify the header type

It is fully valid to use an sd-jwt without any context of sd-jwt-vc maybe I am missing something?

[cre8]

So to be compliant to the spec you can not use only sd-jwt as the credential format, you need an implementation of the class to specify the header type

It is fully valid to use an sd-jwt without any context of sd-jwt-vc maybe I am missing something?

The spec for sd-jwt has no mentioning to set the typ field to sd-jwt since this is out of scope of the specification. That's why the spec for sd-jwt-vc was written because it is dealing with a specific implementation of the usage of the sd-jwt algorithms.

To be compliant with the jwt spec, the typ value has to be one of the IANA Media Types. It will include sd-jwt-vc once the spec is finalised, but it will not include sd-jwt since this is not a credential format.

I don't feel good to allow people to give out sd-jwt as typ because it's a non standardised approach and will lead to interoperability issues.

[berendsliedrecht]

So to be compliant to the spec you can not use only sd-jwt as the credential format, you need an implementation of the class to specify the header type

It is fully valid to use an sd-jwt without any context of sd-jwt-vc maybe I am missing something?

The spec for sd-jwt has no mentioning to set the typ field to sd-jwt since this is out of scope of the specification. That's why the spec for sd-jwt-vc was written because it is dealing with a specific implementation of the usage of the sd-jwt algorithms.

To be compliant with the jwt spec, the typ value has to be one of the IANA Media Types. It will include sd-jwt-vc once the spec is finalised, but it will not include sd-jwt since this is not a credential format.

I don't feel good to allow people to give out sd-jwt as typ because it's a non standardised approach and will lead to interoperability issues.

I understand your point, however the typ claim is optional. Meaning an sd-jwt can be fully valid without having a typ claim.

Also, the sd-jwt-vc spec was not only written to define the typ field and has more uses.

[cre8]

So to be compliant to the spec you can not use only sd-jwt as the credential format, you need an implementation of the class to specify the header type

It is fully valid to use an sd-jwt without any context of sd-jwt-vc maybe I am missing something?

The spec for sd-jwt has no mentioning to set the typ field to sd-jwt since this is out of scope of the specification. That's why the spec for sd-jwt-vc was written because it is dealing with a specific implementation of the usage of the sd-jwt algorithms.
To be compliant with the jwt spec, the typ value has to be one of the IANA Media Types. It will include sd-jwt-vc once the spec is finalised, but it will not include sd-jwt since this is not a credential format.
I don't feel good to allow people to give out sd-jwt as typ because it's a non standardised approach and will lead to interoperability issues.

I understand your point, however the typ claim is optional. Meaning an sd-jwt can be fully valid without having a typ claim.

Also, the sd-jwt-vc spec was not only written to define the typ field and has more uses.

It depends on the context: like I said: sd-jwt is only the algo, so it has no impact on the type. However sd-jwt-vc forces it.
There is no such sd-jwt as credential, it's only the algorithm for selective disclosure. All the credential format part is defined in and only in the sd-jwt-vc.

So again: sd-jwt should NOT be a class that can be initialized on its own.

[berendsliedrecht]

It depends on the context: like I said: sd-jwt is only the algo, so it has no impact on the type. However sd-jwt-vc forces it.
There is no such sd-jwt as credential, it's only the algorithm for selective disclosure. All the credential format part is defined in and only in the sd-jwt-vc.

I don't think we will reach any consensus here, but sd-jwt is completely usable on its own. Not as a credential format, but as a replacement / addition to normal JWTs. sd-jwt-vc aims to bridge the specific requirements for a credential, however that does not mean that sd-jwt cannot be used in a context outside of credentials. I really feel like we massively limit the usage of this library as sd-jwt will likely, and already is, way larger than sd-jwt-vc and it will be used in contexts outside of digital idenity, ssi, VCs, etc.

If it says anywhere in the specification of sd-jwt that it should not be used directly and only extensions on top of if that define extra requirements can be used, I am perfectly fine with this approach. However I did not see any reference to this and every other sd-jwt implementation also does not take this approach.

[lukasjhan]

FYI: SD JWT VC standard version 2 just released:
https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-02.html#section-1.2

The contents of link describe SD-JWT as a Credential Format.

[cre8]

It depends on the context: like I said: sd-jwt is only the algo, so it has no impact on the type. However sd-jwt-vc forces it.
There is no such sd-jwt as credential, it's only the algorithm for selective disclosure. All the credential format part is defined in and only in the sd-jwt-vc.

I don't think we will reach any consensus here, but sd-jwt is completely usable on its own. Not as a credential format, but as a replacement / addition to normal JWTs. sd-jwt-vc aims to bridge the specific requirements for a credential, however that does not mean that sd-jwt cannot be used in a context outside of credentials. I really feel like we massively limit the usage of this library as sd-jwt will likely, and already is, way larger than sd-jwt-vc and it will be used in contexts outside of digital idenity, ssi, VCs, etc.

If it says anywhere in the specification of sd-jwt that it should not be used directly and only extensions on top of if that define extra requirements can be used, I am perfectly fine with this approach. However I did not see any reference to this and every other sd-jwt implementation also does not take this approach.

But isn't each JWT is a credential since it includes signed claims? It does not include the "proof of ownership" by binding a holders public key. SD-JWT-VC is not requiring this.
My biggest concern making the SdJWTInstance not abstract is that one side will use this approach, and the other SdJWTVCInstance, thinking both are doing the same thing.

I totally agree that the SD-Algorithm can be used for anything else, but then we need to split it up from the JWT part and then we can use it for non credentials.

[cre8]

@berendsliedrecht so we have two options:

• Making SDJWTInstance not abstract and SDJWTVCInstance will just set the typ and validation function
• staying abstract and mention in the readme how to use the native sdjwtInstance class

What way do you prefer, I am fine with both

[lukasjhan]

If we allow people to use pure sd-jwt, then I think

Making SDJWTInstance not abstract and SDJWTVCInstance will just set the typ and validation function

is better :) They can use it easily without extending it.

[berendsliedrecht]

@berendsliedrecht so we have two options:

• Making SDJWTInstance not abstract and SDJWTVCInstance will just set the typ and validation function

• staying abstract and mention in the readme how to use the native sdjwtInstance class

What way do you prefer, I am fine with both

Id have to stay with option one. I hope my Saturday will stay free and I can give a whole lot more into the codebase and get a bit of a better sense of these exact complications.

People should be able to create an sd-jwt without creating a class for it first and as long as that is possible, I am happy with it :).