By Peter Strobel
JSON-LD W3C Verifiable Credentials are a popular credential format in the Decentralized Identity community. They complement the Anonymous Credentials (AnonCreds) credential format; both formats are supported by Aries Cloud Agent – Python (ACA-Py) and can be combined to fulfill a variety of use cases. This credential format was the subject of our Indicio Meetup last monday, and we hope those who attended took away valuable insights into the utility of JSON-LD credentials! During the incredible meetup, the Indicio experts covered five points key to understanding JSON-LD credentials and their use in ACA-Py!
Five Main Takeaways:
1) What are JSON-LD Credentials?
Starting with the name, JSON-LD stands for JavaScript Object Notation with Linked Data. JSON-LD is a method of encoding linked data using JSON. The term “JSON-LD Credential” alone is somewhat ambiguous but the way it is colloquially used, it means a W3C Verifiable Credential Data Model compliant credential signed using Linked Data Proofs. These are more precisely referred to as Linked Data Proof Verifiable Credentials (LDP-VCs).
2) Why JSON-LD Credentials?
LDP-VCs can be held and presented by anyone, whether they are the subject of the credential or not! This handy feature allows a holder to present authentic data about a party other than ourselves. It may seem counterintuitive from an AnonCreds perspective, where privacy and control are guiding principles. However, in the case where we need credentials from public entities whose claims are about public information, the process of exchanging verifiable information becomes incredibly easy.
Additionally, LDP-VCs cryptography is simpler when compared to AnonCreds’ Camenisch-Lysyanskaya (CL) signatures. CL signatures require Rivest-Shamir-Adleman (RSA) keys, which are large and potentially slow in constrained environments like Internet of Things (IoT). While there is specialized crypto hardware for IoT and similar constrained platforms, CL signatures are not widely supported on those modules. LDP-VCs, however, support multiple commonly-supported signature types, such as ED25519, BBS+, and JWS2020 (although for now, ACA-Py only supports ED25519 and BBS+).
3) Key Components + Features of LDP-VCs:
Type Property: Denotes the type of verifiable credential (passport, driver’s license, etc.). Helps processors determine if the object provided is appropriate for its goal. For example, you wouldn’t provide a driver’s license if you needed to get onto an international flight.
Issuer Property: Denotes the Issuer of a verifiable credential. This will generally be the Issuer’s DID.
Issuance Date: Denotes the date and time at which a credential becomes valid. Must be present and must be in XML dateTime format.
Credential Subject Property: Contains claims about one or more subjects. Must contain one or more objects containing one or more claims. In AnonCreds terms, we would call these “credential attributes.”
Context Property: Must contain all terms used in the credential. In LDP-VCs, you can specify many contexts; if your credential has multiple (and most will, since all must at least contain the core context which doesn’t define any claim terms), all contexts are joined together. If a term used in the credential is not found in these joined contexts, the document is not considered valid. In AnonCreds terms, this could be considered the equivalent of a credential schema
Proof Property: Enables verification of the claims expressed in a LDP-VC. At least one proof mechanism and the details necessary to evaluate the proof must be present.
4) Similarities to AnonCreds:
Where Indy AnonCreds uses credential schema’s to define credential attributes, LDP-VCs use what are known as “contexts,” as described above in Take Away #1. While the feature seems odd, these are similar to AnonCreds schemas, but there are some differences worth mentioning.
a. An LDP-VCs context defines the terms used in the credential, including claim attribute names, type, issuer, issuance date, and other core credential properties. AnonCreds schemas, however, only define two credential terms: attributes and claims.
b. Contexts must contain all terms used in the credential, and in JSON-LD you can specify many contexts! If your credential has multiple contexts, all are joined together Frankenstein style. AnonCreds has a similar requirement that all attributes found in a credential must be found within the schema, but does not permit joining together different schemas.
5) Use in ACA-Py:
While AnonCreds can use issue-credential v1 protocol with either present-proof v1 or v2, LDP-VCs in ACA-Py are only compatible with issue-credential v2 and present-proof v2 protocols, as they are flexible enough and have a sufficiently long list of supported signature types. This means that support for v2 versions of both protocols will need to be added to your agents in addition to LDP-VC support. ACA-Py supports both protocols, but you will need to adjust your controllers to the new v2 endpoints to take advantage of them.
LDP-VCs are still being developed through contribution and discussion within the Hyperledger community, and you can contribute too! Several open source groups are looking for new members, including the DIDComm Users Group (DIDComm UG), ACA-Py Users Group (ACAPUG), and Aries Working Group (AWG). You can find more information on open source projects Indicio contributes to here.
The Hyperledger Discord is also an excellent resource for engaging with the community/getting up to date on the latest code pushes. Discussion is always active as newer ACA-Py versions are getting released! Code contributions are also appreciated, though we do encourage people to stay up-to-date with community calls or open a GitHub issue before making major changes, to make sure contributions can be merged.
To learn more about JSON-LDs and ACA-Py we encourage you to watch the latest Indicio Insights, or for a deeper dive, you can watch the recording of a full meetup recently hosted by myself and Daniel Bluhm on the topic.
The next Indicio Meetup is scheduled for December 13 and will feature Andin C.G. Bikker of Aruba, Nancy Norris of British Columbia’s Ministry for Energy, and Elizabeth M. Tanner, Esq., Secretary of Commerce, Rhode Island for a conversation on decentralized identity, digital transformation, and government.
