Closed OR13 closed 4 years ago
Identitywoman
commented
4 years ago I agree with Orie that not confusing developers is critical. There are two formats that are enclosed within the VC specification that is an official W3C spec. It behooves us to not confuse developers when only one format is supported by the libraries in this repo.
tplooker
commented
4 years ago +1 to the points raised above. In addition to this a feature that might be of interest, is support for assertions supporting selective reveal (e.g via zero knowledge proofs). JWS (JSON Web Signatures) treat the signed payload as a single blob, this limitation prevents using selective reveal compatible digital signatures such as BBS signatures without applying some form of normalization process to the payload, a feature that is already built into linked data proofs, current spec here and reference implementation.
beejones
commented
4 years ago Thanks for sharing. We are currently in private preview so prioritized on one format. We take this into account for future releases.
OR13
commented
4 years ago If you want test vectors for both JWT and LD Proof VCs, we have some here:
beejones
commented
4 years ago Cool. Thanks
beejones
commented
4 years ago @OR13 , @tplooker , @Identitywoman I wanted to let you know that the development of json ld proofs have started. Thanks
Per the VC Data Model there are 2 proof formats defined: https://www.w3.org/TR/vc-data-model/#proof-formats
JWTs provide no semantic features, and have no canonicalization support... But given they have been around for long enough to have a number of cryptographic algorithms prohibited https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms there is an abundance of JOSE tooling to build on.
When we implemented https://identity.foundation/sidetree/spec/#commitment-value-generation
We were forced to require the use of JCS, beyond specifying vanilla JOSE, because, per:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17
In addition to JOSE not having a canonical representation for data, JSON also does not reliably handle big numbers: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17#appendix-D
Big Number are incredibly common when handling crypto currency, or mathematical operations...
Also per the VC Data Model Basic Concepts:
https://www.w3.org/TR/vc-data-model/#basic-concepts
@contextis required, and is used to define the credential as linked data (JSON-LD).The JWT variant's embed these credentials as
vcandvp.https://w3c.github.io/vc-data-model/#json-web-token-extensions
But does this implementation check to make sure they are valid JSON-LD? Or do you treat
vcandvpas arbitrary JSON attributes? If you don't validate them, I don't see the value in VC-JWT at all, since you can get the same result by just creating a vanilla JWS...Finally, LD Proofs are 100% compatible with JOSE, and add support for semantic disambiguity, unlocking common vocabularies such as schema.org and google knowledge graph.... And JSON-LD is already being used by Azure IoT: https://docs.microsoft.com/en-us/azure/iot-pnp/overview-iot-plug-and-play
Bing also supports Schema.org and JSON-LD... https://blogs.bing.com/webmaster/august-2018/Introducing-JSON-LD-Support-in-Bing-Webmaster-Tools
Here is an example of creating an LD Proof for all the popular JOSE key and signature formats, it leverages the best of JOSE (as popular legacy cryptographic suite), along with support canonicalization and compatibility with RDF / schema.org and JSON-LD.
https://github.com/w3c-ccg/lds-jws2020
If you do not plan to support LD Proofs along with JWTs, might I suggest renaming this repo (and the others) to avoid misleading developers who might assume Microsoft is supporting the same linked data technology currently used by Azure IoT and Bing.