signing VC in sd-jwt format

[ThierryThevenet]

Hello
Is there any spec to integrate the sd-jwt format ?

[jrhender]

For previous context, there is this issue discussing JWT support in the VC-API #208
I believe that at the time it was decided not to add JWT support into the spec but I am supportive of revisiting this general JWT question given the progress of the SD-JWT format.

[ThierryThevenet]

Yes, the ARF in EU is now based on this format combined with OIDC4VC. We will add to our own API VC server this feature soon so it would be helpful to have some guidelines.

[msporny]

Yes, the plan is to support issuance of credentials in any format. The VC API is agnostic wrt. the format for the VC.

[podefr]

Hi all,

Has there been any update on that? @msporny regarding jwt VCs, is your last comment here still valid?

We're looking to implement jwt and sd-jwt VCs as part of Hedera's VC API and want to make sure that we're as compliant with the specs as possible.

Regarding sd-jwt, how would you suggest the disclosure frame to be specified? would that be part of the "options" field for instance during issuance of the VC and the VP?

thanks!

[msporny]

Has there been any update on that? @msporny regarding jwt VCs, is your last comment here still valid?

Yes, that last comment is still valid. Some more has happened since that last comment was made:

Support for VC-JWT was removed in the VC-JOSE-COSE specification a while ago and a decision made to only focus on SD-JWT. A few weeks ago, there was agreement to put VC-JWT back into the VC-JOSE-COSE specification. All that to say, support for VC-JWT continues to be shaky at best, just be aware of that as you implement. The design of VC-JWT in v1.1 is changing in VC-JWT 2.0.

We're looking to implement jwt and sd-jwt VCs as part of Hedera's VC API and want to make sure that we're as compliant with the specs as possible.

Great news, I also see that you support Data Integrity. I'm cc'ing @BigBlueHat who runs the VC API test suite initiative and can get you integrated so you can see how compliant you are with all the specs. @BigBlueHat over to you to provide the appropriate READMEs/links.

Regarding sd-jwt, how would you suggest the disclosure frame to be specified? would that be part of the "options" field for instance during issuance of the VC and the VP?

Yeah, probably as part of the options field. You're very much in "navigated waters" at this point since SD-JWT is not a standard, and VC-JWT is undergoing updates for v2.0.

I'd suggest focusing on ecdsa-sd for selective disclosure for now since the spec is in the W3C Candidate Recommendation phase and because there is a test suite for it: https://w3c.github.io/vc-di-ecdsa/#ecdsa-sd-2023

If you continue down the SD-JWT and VC-JWT path, it can be done, but we'd start looking to you for guidance on how you did the integration. It can be done, we know others have done it, but we haven't had the time as a group to get all the implementers together to see how they're passing some of these options to the APIs.

All that said, if it doesn't fit in the payload, yes, pass it via options. Try to pick some options that are either 1) specific to you implementation so they don't conflict w/ the future standard, or 2) going to make sense for the broader industry.

[dlongley]

One way the issuance API could return enveloped (e.g., JWT-secured VCs) is by reusing the EnvelopedCredentialPattern here:

https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-a-presentation-0

This should not require any changes to the return value from the issuance API. It's probably the case that this can be reused in other APIs as well.

[msporny]

The group discussed this on 2024-05-28:

@dlongley noted that this is ready for PR, the issuing/exchange APIs need to return back an enveloped VC, which is specified in VC v2.0, what that expresses is an id that contains a data URL, VC-JWT, SD-JWT, mDoc, can all be expressed in a data URL. You also include media type, if people return digital credentials that way, this is already supported and we just show how this happens. @PatStLouis asked if everything is an enveloped presentation, @dlongley noted that you can envelope both VCs and VPs.

The PR that is raised can specify how to use EnvelopedVerifiableCredentials or EnvelopedVerifiablePresentations to issue/verify different VC formats.

[jrhender]

To further clarify discussion on 2024-05-28 call.

On this point

The PR that is raised can specify how to use EnvelopedVerifiableCredentials or EnvelopedVerifiablePresentations to issue/verify different VC formats.

This PR should not be limited to SD-JWT but be general to the use of EnvelopedVerifiableCredentials/Presentations to issue other credential formats.

[jrhender]

An idea I have for implementing the response body schema is to use the discriminator feature of openapi to adjust the schema of the returned verifiableCredential based on the type property. My idea is that if the type property is EnvelopedVerifiableCredential, then the schema of the returned verifiableCredential must correspond to the schema described in the Enveloped Verifiable Credentials section of the VC 2.0 Data Model spec.

[msporny]

The group discussed this on 2024-09-03:

A PR should be raised to note that an EnvelopedVerifiablePresentation can be used to issue a VP w/ different a different media type (e.g., application/sd-jwt). The note should mention that the media types for enveloped VCs are not final and the spec might change as a result.

[msporny]

PR #417 was merged to address this issue. Closing.