vc-jws

[OR13]

I have a dream:

it("can decode a verifiable credential from a json web signature", async () => {
  const credential = JSON.parse(
    Buffer.from(verifiableCredential.split(".")[1], "base64").toString()
  );
  console.log(credential);
});

That one day verifiable credentials are flexible enough to be used with any popular signing, encryption, or proving system.

[selfissued]

To be clear, your dream is to decouple the VC body from the way that it's secured?

A consequence of this is that we wouldn't be using standard JWT claims such as "iss", "iat", and "exp" to express these values, but other claim names with sometimes different syntax. I know that @nadalin has views on that, per his comments at TPAC and #14.

[OR13]

I'm a strong -1 to must of his comments on #14.

My dream is to allow developers to use JOSE to protect the VCDM core data model which is JSON-LD, and can therefore be trivially secured with JOSE.

I believe the JWT mapping is complexity that many developers have already failed to implement consistently, and which is not necessary.

I think we should be allowed to secure JSON-LD in the following ways:

1. As JWT with a normatively defined mapping that is unambiguous and as simple as possible.
2. As a JWS with a normatively defined mapping that is unambiguous and as simple as possible.
3. As a JWE with a normatively defined mapping that is unambiguous and as simple as possible.

There are lots of use cases where I don't care about JWT, and I just want to use a simple JWS for a large VC, and JWE to encrypt its presentation.

To be clear, I don't think folks should be prevented from securing VCDM with JWT, I think it should not be the only legal way to secure the VCDM with JOSE.

[Sakurann]

per JWS/JWE specs, what is signed/encrypted as JWS/JWE does not have to be a JWT.

• Option 1 would be for the spec can say that JSON-LD Credential must be signed as-is using JWS/JWE without any JWT mapping, but JWT credential MUST use JWT Claims as defined in the spec (I put my suggestion here clarify that vc vp claims do not include entire VC/VPs #4 (comment))
• Option 2 would be to say that even when JSON-LD is used, it MUST be a JWT following certain rules (my suggestion above would still apply)

I don't have a strong preference, but if we can agree on the usage of JWT claims, Option 2 would be more consistent and less complicated.

[OR13]

per JWS/JWE specs, what is signed/encrypted as JWS/JWE does not have to be a JWT.

I was reading this section yesterday: https://www.rfc-editor.org/rfc/rfc7519#section-5.2

There are proposals that have gone to the list and which have not been discussed yet by the WG, they are mentioned here:

• Add media type registration request vc-data-model#1000 (comment)

My proposed solution would be:

Add a section to VC-JWT, that describes how to secure application/credential+ld+json with a JWS.

The only place that normative extensions would apply would be the treatment of the header... and it should be clear how that token is different than a "vc-jwt" under 1.1.

[alenhorvat]

I have a dream:

it("can decode a verifiable credential from a json web signature", async () => {
  const credential = JSON.parse(
    Buffer.from(verifiableCredential.split(".")[1], "base64").toString()
  );
  console.log(credential);
});

That one day verifiable credentials are flexible enough to be used with any popular signing, encryption, or proving system.

Maybe I have an idea. Will try to finish it next week.

[OR13]

This issue should be closed, this is what V2 does now.

[OR13]

Marked pending close over 1 week ago, closing.