mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2024-10-01 01:05:54 -04:00
split json-ld vc 2 pages
This commit is contained in:
⧉ infominer
parent
6f19a9ce9f
commit
da776c41ab
@ -48,6 +48,7 @@ Verifiable Credentials,CCG Mailing List,,,Michael Herman,,,,,,What are VCs simil
|
||||
Verifiable Credentials,Personal,,https://lists.w3.org/Archives/Public/public-credentials/2021Jun/0244.html,"Kyle Den Hartog, Manu Sporny",,,,,,Re: The dangers of using VCs as permission tokens (was: PROPOSALs for VC HTTP API call on 2021-06-22),"Agreed, when it comes to the number of checks that occur it's much greater<br>because of the delegation. With that in mind, looking at the semantics only<br>of the system VCs in my opinion weren't optimally designed for permission<br>tokens. This difference between the two requires that an implementation<br>that wants to support both claims tokens and permissions tokens has to<br>grapple with the different mental model that arise when trying to stuff<br>these things together. This introduces additional complexity. Additionally<br>it leads to weird statements that are being made where it's difficult to<br>tell if the VC is behaving like a claims token or a permissions token.<br><br>Yes, exactly this. Exactly what Kyle states above is the reason why it's so complicated (and thus dangerous) to use VCs as permissions tokens.<br><br>This is one of the primary reasons that we separated out the Authorization Capabilities work from the Verifiable Credentials work. Things get really complicated when you start mixing authz/authn/claims/permissions into a Verifiable Credential. Just because you can do it doesn't mean you should",,https://kyledenhartog.com/example-authz-with-VCs/,,Post,,,Comparisons,,,,,,,,2021-06-24,,,,,,,,,,,,,
|
||||
"Verifiable Credentials, Object Capabilities",Personal,,,Kyle Den Hartog,,,,,,Comparing VCs to ZCAP-LD,Why make the investment then to put the time and effort into ZCAPs when we’ve already got VCs? Simply put because security is hard and trying to push square pegs into round holes often times leads to bugs which are elevated to mission critical authentication/authorization bypass vulnerabilities. By designing around a fit for purpose data model with a well defined problem being solved it allows for us to be much more precise about where we believe extensibility is important versus where normative statements should be made to simplify the processing of the data models. By extension this leads to a simpler security model and likely a much more robust design with fewer vulnerabilities.,,https://kyledenhartog.com/comparing-VCs-with-zcaps/,,Post,,,"Comparisons, Main",,,,,,Object Capabilities,,2021-09-25,,,,,,,,,,,,,
|
||||
"Verifiable Credentials, Object Capabilities",CCG Mailing List,,,Dave Longley,,,,,,Re: VCs - zCaps / OCap a Discussion,"TL; DR: My current view is that the main confusion here may be over the difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a generalized container for attaching a cryptographic proof to a document. That's what LD proofs (or JOSE style proofs) are for. VCs *use* LD proofs (or JOSE style proofs) to attach an assertion proof to a document that specifically models statements made by an issuer about some subject, which is therefore inherently about the identity of that subject",,https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0027.html,,Discussion,,,"Comparisons, Main",,,,,,Object Capabilities,Credentials Community Group,2020-12-05,,,,,,,,,,,,,
|
||||
Verifiable Credentials,VCWG,,,,,,,,,List of Implementations for the Verifiable Credentials Data Model,"<ul><li>Go<ul><li><a href=""https://github.com/TBD54566975/ssi-sdk/tree/main/credential"">Credential Manifest Builders</a> (DI & JWT)</li><li><a href=""https://github.com/hyperledger/aries-framework-go"">Hyperledger Aries Framework Go</a> (DI & JWT)</li></ul></li><li>Java<ul><li><a href=""https://github.com/danubetech/verifiable-credentials-java"">Verifiable Credentials Java</a> (DI & JWT)</li></ul></li><li>JavaScript/TypeScript<ul><li><a href=""https://github.com/digitalbazaar/vc-js"">Verifiable Credentials JS Library</a> (DI)</li><li><a href=""https://github.com/transmute-industries/verifiable-data/tree/main/packages/vc.js"">Verifiable Data Credential JS Library with JWT</a> (DI & JWT)</li><li><a href=""https://github.com/decentralized-identity/did-jwt-vc"">W3C Verifiable Credentials and Presentations in JWT format</a> (JWT)</li></ul></li><li>Kotlin<ul><li><a href=""https://github.com/microsoft/VerifiableCredential-SDK-Android"">Verifiable Credentials in Kotlin</a> (JWT)</li></ul></li><li>Python<ul><li><a href=""https://github.com/hyperledger/aries-cloudagent-python"">Hyperledger Aries Cloud Agent - Python (ACA-Py)</a> (DI & JWT)</li></ul></li><li>Rust<ul><li><a href=""https://github.com/spruceid/didkit"">DIDKit</a> (DI & JWT)</li></ul></li><li>Swift<ul><li><a href=""https://github.com/microsoft/VerifiableCredential-SDK-iOS"">Verifiable Credentials in Swift</a> (JWT)</li></ul></li></ul>",,https://github.com/w3c/verifiable-credentials/blob/main/implementations.md,,Page,,,Implementations,,,,,,,,2022-06-03,,,,,,,,,,,,,
|
||||
Verifiable Credentials,DSpace@MIT,,,,,,,,,SolidVC : a decentralized framework for Verifiable Credentials on the web,"SolidVC is a decentralized Verifiable Credentials platform built with the open protocols of the Web. It is implemented on top of Solid, a Web framework developed at MIT in 2016 that allows decentralized applications to interact with personal user data to provide services in an access controlled environment.",,https://dspace.mit.edu/handle/1721.1/121667,https://dspace.mit.edu/bitstream/handle/1721.1/121667/1102055877-MIT.pdf.jpg?sequence=4&isAllowed=y,paper,,,Implementations,,,,,,,,2019,,,,,,,,,,,,,
|
||||
Verifiable Credentials,Paris P2P,,,,,,,,Paris P2P Festival,Blockstack and Verifiable Credentials - Paris P2P Festival,• Keep auth and smart contracts on-chain<br> • Keep encrypted data off-chain<br> > • Wrap everything in an easy JavaScript API,,https://p2p.paris/gen/attADzQJ92rNIv6B3-Blockstack_and_Verifiable_Credentials_-_Paris_P2P_Festival_.pdf,,presentation,,,Implementations,,,,,,,,2020-01-10,,,,,,,,,,,,,
|
||||
Verifiable Credentials,LibP2P,,,,,,,,,Verifiable credentials and libp2p,Hi - we’re looking into libp2p as a network stack for our application and exploring how we could integrate verifiable credentials (https://w3c.github.io/vc-data-model/ 2) infrastructure. A basic use case is that of a node being challenged to provide some specific credential to join the network. The bootstrap node handling the incoming connection should verify the credential with the issuer and complete the connection/bootstrap or terminate it.,,https://discuss.libp2p.io/t/verifiable-credentials-and-libp2p/206,https://global.discourse-cdn.com/standard17/uploads/libp2p/original/1X/aacb49457c3aace79a1038dd02996b402260215d.png,discussion,,,Implementations,,,,,,,,2019-07-09,,,,,,,,,,,,,
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Verifiable Credentials - W3C"
|
||||
title: "Verifiable Credentials - Literature, Comparisons, Explainer (W3C)"
|
||||
name: Verifiable Credentials
|
||||
layout: standards
|
||||
headings: ["About","Comparisons","Implementations","Literature","Use Case"]
|
||||
@ -9,6 +9,7 @@ excerpt: >
|
||||
tags: ["W3C","Verifiable Credentials","Credentials Community Group","VC-WG","JSON-LD","Claims and Credentials WG"]
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
permalink: web-standards/w3c/verifiable-credentials/
|
||||
canonical_url: https://decentralized-id.com/web-standards/w3c/verifiable-credentials/
|
||||
header:
|
||||
image: /images/verifiable-credentials_head.webp
|
||||
caption: "[Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)"
|
||||
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "Hyperledger Anoncreds: Attribute Based Credentials"
|
||||
description: Anoncreds has been modularized from the Hyperledger Indy blockchain framework.
|
||||
excerpt: >
|
||||
Hyperledger AnonCreds – short for “Anonymous Credentials”- is the most commonly used Verifiable Credential (VC) format in the world. Ledger agnostic and with a formal open specification, AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.
|
||||
layout: single
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
tags: ["Hyperledger Foundation","IBM","IDEMIX","Anoncreds","Sovrin Foundation","Evernym","ZKP-CL"]
|
||||
permalink: /projects/hyperledger/anoncreds/
|
||||
canonical_url: 'https://decentralized-id.com/projects/hyperledger/anoncreds/'
|
||||
last_modified_at: 2023-07-02
|
||||
---
|
||||
|
||||
## Main
|
||||
[Website](https://www.hyperledger.org/use/anoncreds) - [Specification](https://github.com/hyperledger/anoncreds-spec) - [Specification V2](https://github.com/hyperledger/anoncreds-spec-v2)
|
||||
|
||||
> Hyperledger AnonCreds – short for “Anonymous Credentials”- is the most commonly used Verifiable Credential (VC) format in the world. Ledger agnostic and with a formal open specification, AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.
|
||||
|
||||
* [anoncreds-rs](https://github.com/hyperledger/anoncreds-rs) 2023-06-02 Hyperledger
|
||||
> Rust library and reference implementation of the [Anoncreds V1.0](https://hyperledger.github.io/anoncreds-spec/) specification.
|
||||
* [Hyperledger launches new digital identity project, AnonCreds](https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/) 2022-11-15
|
||||
> The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.
|
||||
|
||||
## Working Group
|
||||
|
||||
* [AnonCreds Specification Working Group](https://wiki.hyperledger.org/display/ANONCREDS/AnonCreds+Specification+Working+Group) 2022-11-02
|
||||
> The AnonCreds Specification Working Group operates under the Community Specification License v1.0 to create the AnonCreds Specification. Current work is focused on Version 1.0 of the specification that covers the current CL-Signatures-based implementation of AnonCreds agnostic to the underlying ledger.
|
||||
* [Video] [Hyperledger AnonCreds Specification Working Group](https://www.youtube.com/watch?v=sUcstipdEm8) 2023-06-19 Hyperledger Foundation
|
||||
> The big thing I want to talk about was a couple of things on revocation approaches and and go over possibilities. There, there's a few things happening that I wanted to share. [...] as I mentioned in our credits announcements, the 0.1.0 rust implementation was officially released
|
||||
|
||||
## Development
|
||||
|
||||
* [Hyperledger AnonCreds Workshop: Using ZKP Verifiable Credentials Everywhere](https://www.youtube.com/watch?v=1RrJky42dvg) Hyperledger Foundation
|
||||
> AnonCreds was accepted as an Incubated project at Hyperledger in late 2022. This is the first workshop developed by this community and it is intended for anyone interested in using Zero Knowledge Proofs (ZKPs) in a wide variety of contexts.
|
||||
|
||||
## Background
|
||||
- [Anonymous Credential Part 1: Brief Overview and History](https://medium.com/finema/anonymous-credential-part-1-brief-overview-and-history-c6679034c914) 2020-10-01
|
||||
> An anonymous credential (Anoncred), which is also known as an attribute-based credential (ABC), is a concept for a digital credential that provides a credential holder maximal privacy and an ability to selectively disclose their personal information.
|
||||
- [Anonymous Credential Part 2: Selective Disclosure and CL Signature](https://medium.com/finema/anonymous-credential-part-2-selective-disclosure-and-cl-signature-b904a93a1565) 2021-02-04
|
||||
> selective disclosure and an anonymous credential (Anoncred) relies on an efficient signature scheme that supports multiple messages with a single signature. One such signature scheme is known as CL signature that is named after its Jan Camenisch and Anna Lysyanskaya […] CL signature popularized Anoncreds, and it also served as a cryptographic building block in Identity Mixer (Idemix) and Hyperledger Indy projects.
|
||||
* [Wrapping Indy Credentials (AnonCreds) in W3C VCs](https://hackmd.io/S6e2MeSWTICnV9lD9OukKg) 2021-04-12
|
||||
> AnonCreds are typically bound to a holder by using a link secret and not by issuing a credential to a public DID. In order to add such a credential (or a subset of attributes) to the public profile, we suggest the following mechanism which expresses the intent: I self-attest that I have this credential with the specific attribute values, if you require a proof you can ask me using the Aries present proof protocol.
|
||||
|
||||
## Critique
|
||||
|
||||
* [Being “Real” about Hyperledger Indy & Aries / Anoncreds](https://identitywoman.net/being-real-about-hyperledger-indy-aries-anoncreds/) 2022-09-10 IdentityWoman
|
||||
> This article surfaces a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds, the most marketed Self-Sovereign Identity technical stack. It is aimed to provide both business and technical decision makers a better understanding of the real technical issues and related business risks of Hyperledger Indy & Aries / Anoncreds, which have not been shared and discussed openly or publicly as the author believes need to be.
|
||||
|
||||
### Response
|
||||
|
||||
* [Hyperledger launches new digital identity project, AnonCreds](https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/) 2022-11-15
|
||||
> The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.
|
||||
* [A response to Identity Woman's recent blog post about Anoncreds](https://kyledenhartog.com/response-to-anoncreds-criticism/) 2022-09-08 Kyle Den Hartog
|
||||
> It’s only when I started to take a step back that I realized that the architecture of Indy being a private, permissioned ledger leaves it heading in the same direction as many large corporations now extinct browser and intranet projects for many of the same reasons.
|
||||
* [Moving Toward Identity Technology Ready for Mass Adoption](https://trinsic.id/moving-toward-identity-technology-ready-for-mass-adoption/) 2022-09-09 Trinsic
|
||||
> when we realized our customers were facing critical limitations caused by the underlying tech stack, we began developing an updated version of our platform that would reduce our dependency on these technologies and enable a better platform for our customers.
|
||||
|
||||
## Prior Work
|
||||
* [How is IDEMix Implemented?](https://forum.sovrin.org/t/how-idemex-is-implemented-in-sovrin-indy/)
|
||||
> Identity Mixer is not directly (re)implemented by Sovrin, but its cryptographic foundations are very similar, and Sovrin’s implementation includes most of its extended features (predicates, multi-credential, revocation, advanced issuance…). One of the researchers who helped to create Identity Mixer is on Sovrin’s Technical Governance Board and has offered insight to keep the implementations aligned on goals and methods.
|
||||
* [IDEMIX Blog](https://idemix.wordpress.com/)
|
||||
* [ABC4Trust—Attribute-based Credentials for Trust](https://abc4trust.eu/)
|
||||
* [Concepts and Features of Privacy-Preserving Attribute-Based Credentials](https://github.com/p2abcengine/p2abcengine/wiki/Concepts-and-features)
|
||||
* [Concepts and Languages for Privacy-Preserving Attribute-Based Authentication](http://dl.ifip.org/db/conf/idman/idman2013/CamenischDLNPP13.pdf)
|
||||
@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "Verifiable Credentials with JSON-LD and Linked Data Proofs"
|
||||
layout: single
|
||||
description: An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof
|
||||
excerpt: >
|
||||
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~~ [Data Integrity Proofs] Verifiable Credentials (LDP-VCs).
|
||||
header:
|
||||
image: "/images/Verifiable-Credentials-Flavors-Explained_JSON-LD_LD-Proof.webp"
|
||||
caption: "[[**Verifiable Credentials Flavors Explained**]](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [[**infographic**]](https://www.lfph.io/wp-content/uploads/2021/04/Verifiable-Credentials-Flavors-Explained-Infographic.pdf)"
|
||||
teaser: /images/Verifiable-Credentials-Flavors-Explained_jsonld-lds-teaser.webp
|
||||
tags: ["W3C","Verifiable Credentials","JSON-LD","Data Integrity"]
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
permalink: /web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs/
|
||||
last_modified_at: 2023-09-29
|
||||
---
|
||||
|
||||
## Main
|
||||
* [Working Draft] [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) 2023-09-02 - Securing the Integrity of Verifiable Credential Data
|
||||
> This specification describes mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementors of distributed systems.
|
||||
* [Editors Draft] [Verifiable Credentials Data Model v2.0](https://w3c.github.io/vc-data-model/#securing-verifiable-credentials) 2023-09-09
|
||||
> This specification recognizes two classes of securing mechanisms: those that use external proofs and those that use embedded proofs. An external proof is one that wraps an expression of this data model, such as via a JSON Web Token, which is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof, which is elaborated on in Verifiable Credential Data Integrity [[VC-DATA-INTEGRITY](https://www.w3.org/TR/vc-data-integrity/)].
|
||||
>
|
||||
> It should be noted that these two classes of securing mechanisms are not mutually exclusive.
|
||||
* [Final Community Group Report] [JSON Web Signature 2020](https://w3c-ccg.github.io/lds-jws2020/) 2022-07-21
|
||||
> This specification describes a JSON Web Signature Suite created in 2020 for the Linked Data Proof specification. The Signature Suite utilizes Detached JWS signatures to provide support for a subset of the digital signature algorithms registered with IANA.
|
||||
* [Verifiable data](https://learn.mattr.global/docs/concepts/verifiable-data) 2020-12-12 Mattr
|
||||
> Verifiable credentials make use of JSON-LD to extend the data model to support dynamic data vocabularies and schemas. This allows us to not only use existing JSON-LD schemas, but to utilize the mechanism defined by JSON-LD to create and share new schemas as well. To a large extent this is what JSON-LD was designed for; the adoption and reuse of common data vocabularies.
|
||||
>
|
||||
> This type of verifiable credential is best characterised as a kind of Linked Data Proof. It allows issuers to make statements that can be shared without loss of trust because their authorship can be verified by a third party.
|
||||
|
||||
## About
|
||||
* [Linked Data Proofs - A new pathway for verifiable credentials](https://www.linkedin.com/pulse/linked-data-proofs-new-pathway-verifiable-credentials-gokul-alex) 2023-05-13 Gokul Alex
|
||||
> It is portable because it provides a standard vocabulary. JSON-LD configuration files are human readable unlike the JWT. Data schema emerge as important paradigms in this model. VCs based on Linked Data Proofs use Linked Data Signatures for security. They are more granular as they are attribute based rather than credential based.
|
||||
* [Five Things You Need to Know About JSON-LD Credentials in Hyperledger Aries Cloudagent Python](https://indicio.tech/five-things-you-need-to-know-about-json-ld-credentials-in-hyperledger-aries-cloudagent-python/) 2022-12-07 Tim Spring, Indicio
|
||||
> 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).
|
||||
* [Verifying Verifiable Credentials](https://grotto-networking.com/blog/posts/jsonldProofs.html) 2022-11-11 Grotto Networking
|
||||
> A number of specifications and emerging specifications explain and specify how VCs can be “secured”. Here we will look at the “digital signing” of VCs and draw upon the following specifications:
|
||||
> - Verifiable Credential Data Integrity 1.0 Securing the Integrity of Verifiable Credential Data Latest as of October 2022.
|
||||
> - JSON-LD Website
|
||||
> - JSON-LD 1.1 A JSON-based Serialization for Linked Data, W3C Recommendation 16 July 2020.
|
||||
> - EdDSA Cryptosuite v2020 Draft Community Group Report 31 October 2022
|
||||
* [notes] [Verifiable Credentials & Linked Data Proofs](https://hackmd.io/@animo/HJn4Mioku) 2021-04-01
|
||||
> Linked Data Proofs provide a mechanism to for ensuring the authenticity and integrity of Linked Data documents using mathematical proofs.
|
||||
* [Notes on Linked Data Proofs](https://hackmd.io/inzaVCAtSdWQxzmw8doNGg) 2021-01-24
|
||||
> Linked Data Proofs can be used to:
|
||||
> - Make statements without the loss of trust (e.g. VCs or social media posts)
|
||||
> - Authenticate an entity is identified by a certain identifier (e.g. DIDs)
|
||||
> - Delegate authorization for actions to remote environments (e.g. ZCAP-LD)
|
||||
> - Agree to contracts (where agreement can be verified by other parties)
|
||||
> - Integrity protection (e.g. making document tamper-evident)
|
||||
* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [Presentation](https://www.slideshare.net/Kaliya/verifiable-credentials-explained-by-cci)
|
||||
> In the VC Implementation Guidelines, there is a long list of the different characterizations of methods: JSON with JWT’s support vs JSON-LD with LD Signatures, [Benefits of JWT](https://www.w3.org/TR/vc-imp-guide/#benefits-of-jwts), [Benefits of JSON-LD and LD-Proofs](https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs).
|
||||
>
|
||||
> To summarize the most salient points:
|
||||
>
|
||||
> JSON is an older standard, officially recognized as a standard in 2013. JSON-LD 1.0 was formally standardized in 2014. The version and standard was updated to JSON-LD 1.1 and ratified in 2020.
|
||||
>
|
||||
> That being said, one can use JSON libraries to process JSON-LD objects/documents, and conversely, [interpret JSON documents as JSON-LD](https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld) by providing a context.
|
||||
* [JWT vs Linked Data Proofs: comparing Verifiable Credentials](https://medium.com/mattr-global/jwt-vs-linked-data-proofs-comparing-vc-assertion-formats-a2a4e6671d57) 2020-05-7 Nader Helmy, Mattr
|
||||
> Linked Data Signatures provide a simple security protocol which is native to JSON-LD. They are built to compactly represent proof chains and allow a VC to be easily protected on a more granular basis; per-attribute, instead of per-credential. These features support a much more robust security model which has broader implications downstream from VCs, especially in terms of size and efficiency.
|
||||
|
||||
## Development
|
||||
|
||||
* [MDL, JWT-VC, LD-Proofs] [OpenID for Verifiable Presentations](https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html#name-ldp-vcs) 2022-12-30 OpenID
|
||||
> This specification defines mechanisms to
|
||||
> - request presentation of Verifiable Credentials in arbitrary formats.
|
||||
> - provide a verifier with one or more Verifiable Presentations in a secure fashion.
|
||||
> - customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].
|
||||
> - combine the credential presentation with user authentication through [SIOPv2].
|
||||
> - combine the credential presentation with the issuance of OAuth access tokens.
|
||||
@ -1,135 +0,0 @@
|
||||
---
|
||||
title: "Verifiable Credentials with JSON-LD + Data-Integrity Proofs (Linked Data Proofs / BBS)"
|
||||
layout: single
|
||||
description: An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof
|
||||
excerpt: >
|
||||
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~~ [Data Integrity Proofs] Verifiable Credentials (LDP-VCs).
|
||||
header:
|
||||
image: "/images/Verifiable-Credentials-Flavors-Explained_jsonld-data-integrity_lds_bbs+.webp"
|
||||
caption: "[[**Verifiable Credentials Flavors Explained**]](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [[**infographic**]](https://www.lfph.io/wp-content/uploads/2021/04/Verifiable-Credentials-Flavors-Explained-Infographic.pdf)"
|
||||
teaser: /images/Verifiable-Credentials-Flavors-Explained_jsonld-lds-teaser.webp
|
||||
tags: ["W3C","Verifiable Credentials","JSON-LD","LD-Proof","Data Integrity","BBS"]
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
permalink: /web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs+bbs/
|
||||
last_modified_at: 2023-09-09
|
||||
---
|
||||
|
||||
## Main
|
||||
* [Working Draft] [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) 2023-09-02 - Securing the Integrity of Verifiable Credential Data
|
||||
> This specification describes mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementors of distributed systems.
|
||||
* [Editors Draft] [Verifiable Credentials Data Model v2.0](https://w3c.github.io/vc-data-model/#securing-verifiable-credentials) 2023-09-09
|
||||
> This specification recognizes two classes of securing mechanisms: those that use external proofs and those that use embedded proofs. An external proof is one that wraps an expression of this data model, such as via a JSON Web Token, which is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof, which is elaborated on in Verifiable Credential Data Integrity [[VC-DATA-INTEGRITY](https://www.w3.org/TR/vc-data-integrity/)].
|
||||
>
|
||||
> It should be noted that these two classes of securing mechanisms are not mutually exclusive.
|
||||
* [BBS+, Data Integrity] [Formalising Linked-Data based Verifiable Credentials for Selective Disclosure](https://sako-lab.jp/download.php?article=ssr2022_proceedings_dan.pdf) 2022 Dan Yamamoto, Yuji Suga, Kazue Sako IEEE
|
||||
> Abstract—In this paper, we propose a formal definition for Linked-Data based verifiable credential to enable secure selective disclosure among one or multiple verifiable credentials a user has. Previous schemes considered using a single verifiable credential and could not hide the user’s identifying information when performing selective disclosure. We propose the first Linked-Data based verifiable credentials that can perform selective disclosure free from the restrictions the previous scheme had, and prove its property. We also discuss a novel use of combining multiple certificates issued by independent issuers to still allow users to perform selective disclosure on the set of credentials. Our scheme has been implemented as an open source Web-based application that generates a verifiable presentation for a given selection of attributes. The performance evaluation is also provided in the paper.
|
||||
* [Final Community Group Report] [JSON Web Signature 2020](https://w3c-ccg.github.io/lds-jws2020/) 2022-07-21
|
||||
> This specification describes a JSON Web Signature Suite created in 2020 for the Linked Data Proof specification. The Signature Suite utilizes Detached JWS signatures to provide support for a subset of the digital signature algorithms registered with IANA.
|
||||
|
||||
## Verifiable Credentials with Linked Data Proofs
|
||||
* [Linked Data Proofs - A new pathway for verifiable credentials](https://www.linkedin.com/pulse/linked-data-proofs-new-pathway-verifiable-credentials-gokul-alex) 2023-05-13 Gokul Alex
|
||||
> It is portable because it provides a standard vocabulary. JSON-LD configuration files are human readable unlike the JWT. Data schema emerge as important paradigms in this model. VCs based on Linked Data Proofs use Linked Data Signatures for security. They are more granular as they are attribute based rather than credential based.
|
||||
* [Five Things You Need to Know About JSON-LD Credentials in Hyperledger Aries Cloudagent Python](https://indicio.tech/five-things-you-need-to-know-about-json-ld-credentials-in-hyperledger-aries-cloudagent-python/) 2022-12-07 Tim Spring, Indicio
|
||||
> 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).
|
||||
* [Verifying Verifiable Credentials](https://grotto-networking.com/blog/posts/jsonldProofs.html) 2022-11-11 Grotto Networking
|
||||
> A number of specifications and emerging specifications explain and specify how VCs can be “secured”. Here we will look at the “digital signing” of VCs and draw upon the following specifications:
|
||||
> - Verifiable Credential Data Integrity 1.0 Securing the Integrity of Verifiable Credential Data Latest as of October 2022.
|
||||
> - JSON-LD Website
|
||||
> - JSON-LD 1.1 A JSON-based Serialization for Linked Data, W3C Recommendation 16 July 2020.
|
||||
> - EdDSA Cryptosuite v2020 Draft Community Group Report 31 October 2022
|
||||
* [notes] [Verifiable Credentials & Linked Data Proofs](https://hackmd.io/@animo/HJn4Mioku) 2021-04-01
|
||||
> Linked Data Proofs provide a mechanism to for ensuring the authenticity and integrity of Linked Data documents using mathematical proofs.
|
||||
* [Notes on Linked Data Proofs](https://hackmd.io/inzaVCAtSdWQxzmw8doNGg) 2021-01-24
|
||||
> Linked Data Proofs can be used to:
|
||||
> - Make statements without the loss of trust (e.g. VCs or social media posts)
|
||||
> - Authenticate an entity is identified by a certain identifier (e.g. DIDs)
|
||||
> - Delegate authorization for actions to remote environments (e.g. ZCAP-LD)
|
||||
> - Agree to contracts (where agreement can be verified by other parties)
|
||||
> - Integrity protection (e.g. making document tamper-evident)
|
||||
* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [Presentation](https://www.slideshare.net/Kaliya/verifiable-credentials-explained-by-cci)
|
||||
> In the VC Implementation Guidelines, there is a long list of the different characterizations of methods: JSON with JWT’s support vs JSON-LD with LD Signatures, [Benefits of JWT](https://www.w3.org/TR/vc-imp-guide/#benefits-of-jwts), [Benefits of JSON-LD and LD-Proofs](https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs).
|
||||
>
|
||||
> To summarize the most salient points:
|
||||
>
|
||||
> JSON is an older standard, officially recognized as a standard in 2013. JSON-LD 1.0 was formally standardized in 2014. The version and standard was updated to JSON-LD 1.1 and ratified in 2020.
|
||||
>
|
||||
> That being said, one can use JSON libraries to process JSON-LD objects/documents, and conversely, [interpret JSON documents as JSON-LD](https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld) by providing a context.
|
||||
* [Verifiable data](https://learn.mattr.global/docs/concepts/verifiable-data) 2020-12-12 Mattr
|
||||
> Verifiable credentials make use of JSON-LD to extend the data model to support dynamic data vocabularies and schemas. This allows us to not only use existing JSON-LD schemas, but to utilize the mechanism defined by JSON-LD to create and share new schemas as well. To a large extent this is what JSON-LD was designed for; the adoption and reuse of common data vocabularies.
|
||||
>
|
||||
> This type of verifiable credential is best characterised as a kind of Linked Data Proof. It allows issuers to make statements that can be shared without loss of trust because their authorship can be verified by a third party.
|
||||
* [JWT vs Linked Data Proofs: comparing Verifiable Credentials](https://medium.com/mattr-global/jwt-vs-linked-data-proofs-comparing-vc-assertion-formats-a2a4e6671d57) 2020-05-7 Nader Helmy, Mattr
|
||||
> Linked Data Signatures provide a simple security protocol which is native to JSON-LD. They are built to compactly represent proof chains and allow a VC to be easily protected on a more granular basis; per-attribute, instead of per-credential. These features support a much more robust security model which has broader implications downstream from VCs, especially in terms of size and efficiency.
|
||||
|
||||
## LD-Proofs Development
|
||||
|
||||
* [MDL, JWT-VC, LD-Proofs] [OpenID for Verifiable Presentations](https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html#name-ldp-vcs) 2022-12-30 OpenID
|
||||
> This specification defines mechanisms to
|
||||
> - request presentation of Verifiable Credentials in arbitrary formats.
|
||||
> - provide a verifier with one or more Verifiable Presentations in a secure fashion.
|
||||
> - customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].
|
||||
> - combine the credential presentation with user authentication through [SIOPv2].
|
||||
> - combine the credential presentation with the issuance of OAuth access tokens.
|
||||
* [Verifiable Credentials Data Integrity Naming Conventions](https://socialhub.activitypub.rocks/t/verifiable-credentials-data-integrity-naming-conventions/3421/1) 2023-07-17 SocialHub
|
||||
> Basically, the question boils down to: If you read __ eddsa-jcs-2022__, do you understand that it is about signing with an Edwards curve based algorithm after normalizing the data with the JSON Canonicalization Scheme?
|
||||
>
|
||||
> Note: Edwards Curve + JCS is not enough to build an algorithm. There’s at least a hashing algorithm missing (and specifying the curve 25519). For details see here 1
|
||||
|
||||
## Verifiable Credentials with JSON-LD + BBS+ Signatures
|
||||
* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young
|
||||
> JSON-LD ZKP with BBS+ Signatures. This approach to VCs is innovative because it brings together different elements from several of the existing approaches to VCs. It is based on the usage of [BBS+ JSON-LD Signatures](https://github.com/mattrglobal/jsonld-signatures-bbs), which is a subclass of [LD Signatures](https://w3c-ccg.github.io/ld-proofs/), in combination with a JSON-LD credential schema. The cryptography behind this mechanism is BBS+ Signatures, which require what’s called a pairing-friendly curve. Existing implementations in the VC ecosystem use the elliptic curve BLS12–381
|
||||
* [BBS+, JSON-LD and Interoperability of Verifiable Credentials](https://medium.com/coinmonks/bbs-json-ld-and-interoperability-of-verifiable-credentials-8bd26b4d3261) 2021-06-20 Coinmonks
|
||||
> In order to request attributes from the credentials JSON-LD frames are used. The credentials and the proofs created by BBS+ signatures are self-describing and do not require a ledger(unlike CL signature based systems like Hyperledger Indy).
|
||||
* [Working Draft] [BBS Cryptosuite v2023 - Securing Verifiable Credentials with Selective Disclosure using BBS Signatures](https://www.w3.org/TR/vc-di-bbs/) 2023-05-24 W3C
|
||||
> This specification defines a set of cryptographic suites for the purpose of creating, verifying and deriving proofs for BBS+ Signatures in conformance with the Data Integrity [VC-DATA-INTEGRITY] specification.
|
||||
>
|
||||
> In general the suites uses the RDF Dataset Normalization Algorithm [RDF-DATASET-NORMALIZATION] to transform an input document into its canonical form. It then uses the statement digest algorithm to digest each statement to be signed individually, finally the digested statements are signed using the defined signature algorithm.
|
||||
>
|
||||
> BBS+ signatures [CFRG-BBS-SIGNATURE] are compatible with any pairing friendly elliptic curve, however the cryptographic suites defined in this document elect to only allow the usage of the BLS12-381 for interoperability purposes.
|
||||
* [Literature] [Revisiting BBS Signatures](https://eprint.iacr.org/2023/275.pdf) 2023, Stefano Tessaro and Chenzhi Zhu
|
||||
> BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’06), and is currently the object of a standardization effort which has led to a recent RFC draft. BBS+ signatures are suitable for use within anonymous credential and DAA systems, as their algebraic structure enables efficient proofs of knowledge of message-signature pairs that support partial disclosure.
|
||||
>
|
||||
> BBS+ signatures consist of one group element and two scalars. As our first contribution, we prove that a variant of BBS+ producing shorter signatures, consisting only of one group element and one scalar, is also secure. The resulting scheme is essentially the original BBS proposal, which was lacking a proof of security. Here we show it satisfies, under the q-SDH assumption, the same provable security guarantees as BBS+. We also provide a complementary tight analysis in the algebraic group model, which heuristically justifies instantiations with potentially shorter signatures.
|
||||
* [SSI Essentials: Zero Knowledge Proof (ZKP) and Selective Disclosure, till death do us part?](https://gataca.io/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/) 2022-01-23 Gataca
|
||||
> Selective disclosure via BBS+ signatures [...]
|
||||
>
|
||||
> Like monoclaim credentials allow users to share specific claims from a VC, BBS+ Signatures is a multi-message digital signature scheme (named after its creators Boneh, Boyen, and Shacham) that gives users the possibility of sharing VCs with only specific attributes revealed. How does it work?
|
||||
>
|
||||
> BBS+ signatures allow a VC holder to derive proofs from the original signature:
|
||||
> - Deriving a proof: When a holder takes the signed VC and hides one, several, or none of the containing claims, creating a new signature (a derived proof) using the Issuer's public key. This derived proof can prove that the holder knows all of the original claims contained in the VC but chooses only to reveal the required ones.
|
||||
> - Verifying a proof: The verifier validates the derived proof using the Issuer's public key. This process enables the verifier to confirm the validity of the proof, proving that the subset of claims was part of an original message signed by the Issuer.
|
||||
* [Why the Verifiable Credentials Community Should Converge on BBS+](https://www.evernym.com/blog/bbs-verifiable-credentials/) 2021-03-24 Evernym
|
||||
> BBS+ LD-Proofs use JSON-LD schemas, so credentials that use them can have a rich, hierarchical set of attributes. Instead of the heavy-handed mechanism for the encoding and canonicalization of attributes values that we’d imagined for Rich Schemas, they use RDF canonicalization and a hash function. Rather than expanding the credential definition, they discarded it, taking advantage of some properties of BBS+ keys which allow for deterministic expansion.
|
||||
|
||||
### VC with BBS+ Development
|
||||
* [Code] [jsonld-signatures-bbs](https://www.npmjs.com/package/@mattrglobal/jsonld-signatures-bbs) 2022-12-18 Mattr Global, NPMJS
|
||||
> The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.
|
||||
>
|
||||
> Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.
|
||||
* [GitHub] [bbs-signatures](https://github.com/mattrglobal/bbs-signatures) 2022-12-21 Mattr Global
|
||||
> BBS+ Signatures are a digital signature algorithm originally born from the work on Short group signatures by Boneh, Boyen, and Shachum which was later improved on in Constant-Size Dynamic k-TAA as BBS+ and touched on again in section 4.3 in Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited .
|
||||
>
|
||||
> BBS+ signatures require a pairing-friendly curve, this library includes support for BLS12-381.
|
||||
>
|
||||
> BBS+ Signatures allow for multi-message signing whilst producing a single output signature. With a BBS signature, a proof of knowledge based proof can be produced where only some of the originally signed messages are revealed at the discretion of the prover.
|
||||
* [GitHub] [jsonld-signatures-bbs](https://github.com/mattrglobal/jsonld-signatures-bbs) Mattr Global
|
||||
> The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.
|
||||
>
|
||||
> Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.
|
||||
>
|
||||
> This library is runnable in browser and Node.js through the WASM based crypto implementation provided by bbs-signatures. Note bbs-signatures also has an optional dependency on node-bbs-signatures which can be used when running in Node.JS environments to obtain better performance. For environments that do not feature WASM support such as react native, bbs-signatures includes an automatic roll back to an asm.js version but note however the performance difference between asm.js and WASM is significant, for those inclined there are runnable benchmarks in bbs-signatures.
|
||||
* [GitHub] [jsonld-signatures-bbs](https://github.com/zkp-ld/jsonld-signatures-bbs) 2023-02-23 ZKP-LD
|
||||
> Experimental: do not use in production
|
||||
> - Based on MATTR's jsonld-signatures-bbs
|
||||
> - Supports termwise selective disclosure, proof of termwise equality, and credential aggregation
|
||||
> - dependencies upgraded
|
||||
> - WASM only; Neon is currently not supported
|
||||
* [GitHub] [bbs-signatures](https://github.com/zkp-ld/bbs-signatures) ZKP-LD
|
||||
> Experimental: do not use in production
|
||||
> - Based on MATTR's bbs-signatures
|
||||
> - Supports termwise selective disclosure, proof of termwise equality, and credential aggregation
|
||||
> - WASM only; Neon is currently not supported
|
||||
* [Implement Compound Proof BBS+ verifiable credentials using ASP.NET Core and MATTR](https://damienbod.com/2021/12/13/implement-compound-proof-bbs-verifiable-credentials-using-asp-net-core-and-mattr/) 2021-12-13 damienbod
|
||||
> This article shows how Zero Knowledge Proofs BBS+ verifiable credentials can be used to verify credential subject data from two separate verifiable credentials implemented in ASP.NET Core and MATTR. The ZKP BBS+ verifiable credentials are issued and stored on a digital wallet using a Self-Issued Identity Provider (SIOP) and OpenID Connect. A compound proof presentation template is created to verify the user data in a single verify.
|
||||
>
|
||||
> Code: https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS
|
||||
@ -8,26 +8,71 @@ header:
|
||||
image: "/images/Verifiable-Credentials-Flavors-Explained_zkp-cl.webp"
|
||||
caption: "[[**Verifiable Credentials Flavors Explained**]](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [[**Infographic**](https://www.lfph.io/wp-content/uploads/2021/04/Verifiable-Credentials-Flavors-Explained-Infographic.pdf)]"
|
||||
teaser: /images/Verifiable-Credentials-Flavors-Explained_zkp-cl-teaser.webp
|
||||
tags: ["W3C","Verifiable Credentials","ZKP-CL","Anoncreds"]
|
||||
tags: ["W3C","Verifiable Credentials","Hyperledger Foundation","IBM","IDEMIX","Anoncreds","Sovrin Foundation","Evernym","ZKP-CL"]
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
permalink: /web-standards/w3c/verifiable-credentials/zkp-cl/
|
||||
last_modified_at: 2023-09-13
|
||||
permalink: /web-standards/w3c/verifiable-credentials/zkp-cl_anoncreds/
|
||||
redirect_from:
|
||||
- /projects/hyperledger/anoncreds/
|
||||
- /web-standards/w3c/verifiable-credentials/zkp-cl/
|
||||
canonical_url: https://decentralized-id.com/web-standards/w3c/verifiable-credentials/zkp-cl_anoncreds/
|
||||
last_modified_at: 2023-09-29
|
||||
---
|
||||
|
||||
## Main
|
||||
[Website](https://www.hyperledger.org/use/anoncreds) - [Specification](https://github.com/hyperledger/anoncreds-spec) - [Specification V2](https://github.com/hyperledger/anoncreds-spec-v2)
|
||||
|
||||
> Hyperledger AnonCreds – short for “Anonymous Credentials”- is the most commonly used Verifiable Credential (VC) format in the world. Ledger agnostic and with a formal open specification, AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.
|
||||
|
||||
* [Hyperledger launches new digital identity project, AnonCreds](https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/) 2022-11-15
|
||||
> The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.
|
||||
* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young
|
||||
> ZKP-CL: This credential format was created specifically to leverage the [CL Signatures](https://link.springer.com/chapter/10.1007/3-540-36413-7_20). JSON-JWT and JSON-LD Signatures each have their own way of representing the meaning of the attributes within a VC. JSON-JWT references an IANA registry and assumes a “closed world” authority model based on that authoritative registry. JSON-LD Signatures use an @context field to reference existing RDF mapping to known dictionaries and assumes an open world model where new terms and definitions can easily be introduced
|
||||
* [Wrapping Indy Credentials (AnonCreds) in W3C VCs](https://hackmd.io/S6e2MeSWTICnV9lD9OukKg) 2021-04-12
|
||||
* [Literature] [A Signature Scheme with Efficient Protocols](https://cs.brown.edu/people/alysyans/papers/camlys02b.pdf) 2001 Jan Camenisch IBM Zurich, Anna Lysyanskaya Brown
|
||||
> Digital signature schemes are a fundamental cryptographic primitive, of use both in its own right, and as a building block in cryptographic protocol design. In this paper, we propose a practical and provably secure signature scheme and show protocols (1) for issuing a signature on a committed value (so the signer has no information about the signed value), and (2) for proving knowledge of a signature on a committed value. This signature scheme and corresponding protocols are a building block for the design of anonymity-enhancing cryptographic systems, such as electronic cash, group signatures, and anonymous credential systems. The security of our signature scheme and protocols relies on the Strong RSA assumption. These results are a generalization of the anonymous credential system of Camenisch and Lysyanskaya
|
||||
|
||||
## Working Group
|
||||
* [AnonCreds Specification Working Group](https://wiki.hyperledger.org/display/ANONCREDS/AnonCreds+Specification+Working+Group) 2022-11-02
|
||||
> The AnonCreds Specification Working Group operates under the Community Specification License v1.0 to create the AnonCreds Specification. Current work is focused on Version 1.0 of the specification that covers the current CL-Signatures-based implementation of AnonCreds agnostic to the underlying ledger.
|
||||
* [Video] [Hyperledger AnonCreds Specification Working Group](https://www.youtube.com/watch?v=sUcstipdEm8) 2023-06-19 Hyperledger Foundation
|
||||
> The big thing I want to talk about was a couple of things on revocation approaches and and go over possibilities. There, there's a few things happening that I wanted to share. [...] as I mentioned in our credits announcements, the 0.1.0 rust implementation was officially released
|
||||
|
||||
## Development
|
||||
|
||||
* [Hyperledger AnonCreds Workshop: Using ZKP Verifiable Credentials Everywhere](https://www.youtube.com/watch?v=1RrJky42dvg) 2023-05-31 Hyperledger Foundation
|
||||
> AnonCreds was accepted as an Incubated project at Hyperledger in late 2022. This is the first workshop developed by this community and it is intended for anyone interested in using Zero Knowledge Proofs (ZKPs) in a wide variety of contexts.
|
||||
* [anoncreds-rs](https://github.com/hyperledger/anoncreds-rs) 2023-06-02 Hyperledger
|
||||
> Rust library and reference implementation of the [Anoncreds V1.0](https://hyperledger.github.io/anoncreds-spec/) specification.
|
||||
|
||||
## Background
|
||||
* [Wrapping Indy Credentials (AnonCreds) in W3C VCs](https://hackmd.io/S6e2MeSWTICnV9lD9OukKg) 2021-04-12 Finema
|
||||
> AnonCreds are typically bound to a holder by using a link secret and not by issuing a credential to a public DID. In order to add such a credential (or a subset of attributes) to the public profile, we suggest the following mechanism which expresses the intent: I self-attest that I have this credential with the specific attribute values, if you require a proof you can ask me using the Aries present proof protocol.
|
||||
* [Anonymous Credential Part 2: Selective Disclosure and CL Signature](https://medium.com/finema/anonymous-credential-part-2-selective-disclosure-and-cl-signature-b904a93a1565) 2021-02-04
|
||||
* [Anonymous Credential Part 2: Selective Disclosure and CL Signature](https://medium.com/finema/anonymous-credential-part-2-selective-disclosure-and-cl-signature-b904a93a1565) 2021-02-04 Finema
|
||||
> selective disclosure and an anonymous credential (Anoncred) relies on an efficient signature scheme that supports multiple messages with a single signature. One such signature scheme is known as CL signature that is named after its Jan Camenisch and Anna Lysyanskaya […] CL signature popularized Anoncreds, and it also served as a cryptographic building block in Identity Mixer (Idemix) and Hyperledger Indy projects.
|
||||
* [Anonymous Credential Part 1: Brief Overview and History](https://medium.com/finema/anonymous-credential-part-1-brief-overview-and-history-c6679034c914) 2020-10-01
|
||||
> An anonymous credential (Anoncred), which is also known as an attribute-based credential (ABC), is a concept for a digital credential that provides a credential holder maximal privacy and an ability to selectively disclose their personal information.
|
||||
* [CL Signatures for Anonymous Credentials](https://blog.goodaudience.com/cl-signatures-for-anonymous-credentials-93980f720d99) 2019-01-14 Will Abramson
|
||||
> A CL Signature is a signature scheme developed by Jan Camenisch and Anna Lysyanskaya. This scheme has some properties that make it ideal for use in an anonymous credential system and is, in fact, the scheme that Sovrin, and I am sure others, currently use. In this post, I will try to synthesise my current understanding of this scheme, including a look at how Sovrin uses it in practice.
|
||||
* [Attribute Based Credentials and Variable Length Data Graphs](https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/AttributeBasedCredentials_and_VariableLengthDataGraphs.md) 2018-02-28
|
||||
> Attribute Based Credentials using Camenisch Lysyanskaya signature schemes typically require a fixed list of attributes defined before issue time in order to validate the correct attribute signature for revealed and unrevealed attributes, including predicate proofs. This poses problems when an attribute based credential system is to be used for arbitrary data graphs or schema definitions with optional fields, multi-valued fields or nested data structures, such as data schemas in wide use, documented on sites like schema.org.
|
||||
>
|
||||
> In an effort to allow JSON-LD data structures to leverage attribute based credentials and zero knowledge signature schemes, this paper outlines differences, requirements and possible options for representing JSON-LD data in attribute based credential schemes such as the one in use by the Sovrin network, implemented in the Hyperledger Indy project.
|
||||
* [Literature] [A Signature Scheme with Efficient Protocols](https://cs.brown.edu/people/alysyans/papers/camlys02b.pdf)
|
||||
Jan Camenisch IBM Zurich, Anna Lysyanskaya Brown
|
||||
> Digital signature schemes are a fundamental cryptographic primitive, of use both in its own right, and as a building block in cryptographic protocol design. In this paper, we propose a practical and provably secure signature scheme and show protocols (1) for issuing a signature on a committed value (so the signer has no information about the signed value), and (2) for proving knowledge of a signature on a committed value. This signature scheme and corresponding protocols are a building block for the design of anonymity-enhancing cryptographic systems, such as electronic cash, group signatures, and anonymous credential systems. The security of our signature scheme and protocols relies on the Strong RSA assumption. These results are a generalization of the anonymous credential system of Camenisch and Lysyanskaya
|
||||
|
||||
## Critique
|
||||
|
||||
* [Being “Real” about Hyperledger Indy & Aries / Anoncreds](https://identitywoman.net/being-real-about-hyperledger-indy-aries-anoncreds/) 2022-09-10 IdentityWoman
|
||||
> This article surfaces a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds, the most marketed Self-Sovereign Identity technical stack. It is aimed to provide both business and technical decision makers a better understanding of the real technical issues and related business risks of Hyperledger Indy & Aries / Anoncreds, which have not been shared and discussed openly or publicly as the author believes need to be.
|
||||
|
||||
### Response
|
||||
|
||||
* [Hyperledger launches new digital identity project, AnonCreds](https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/) 2022-11-15
|
||||
> The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.
|
||||
* [A response to Identity Woman's recent blog post about Anoncreds](https://kyledenhartog.com/response-to-anoncreds-criticism/) 2022-09-08 Kyle Den Hartog
|
||||
> It’s only when I started to take a step back that I realized that the architecture of Indy being a private, permissioned ledger leaves it heading in the same direction as many large corporations now extinct browser and intranet projects for many of the same reasons.
|
||||
* [Moving Toward Identity Technology Ready for Mass Adoption](https://trinsic.id/moving-toward-identity-technology-ready-for-mass-adoption/) 2022-09-09 Trinsic
|
||||
> when we realized our customers were facing critical limitations caused by the underlying tech stack, we began developing an updated version of our platform that would reduce our dependency on these technologies and enable a better platform for our customers.
|
||||
|
||||
## Prior Work
|
||||
* [How is IDEMix Implemented?](https://forum.sovrin.org/t/how-idemex-is-implemented-in-sovrin-indy/)
|
||||
> Identity Mixer is not directly (re)implemented by Sovrin, but its cryptographic foundations are very similar, and Sovrin’s implementation includes most of its extended features (predicates, multi-credential, revocation, advanced issuance…). One of the researchers who helped to create Identity Mixer is on Sovrin’s Technical Governance Board and has offered insight to keep the implementations aligned on goals and methods.
|
||||
* [IDEMIX Blog](https://idemix.wordpress.com/)
|
||||
* [ABC4Trust—Attribute-based Credentials for Trust](https://abc4trust.eu/)
|
||||
* [Concepts and Features of Privacy-Preserving Attribute-Based Credentials](https://github.com/p2abcengine/p2abcengine/wiki/Concepts-and-features)
|
||||
* [Concepts and Languages for Privacy-Preserving Attribute-Based Authentication](http://dl.ifip.org/db/conf/idman/idman2013/CamenischDLNPP13.pdf)
|
||||
@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Verifiable Credentials with JSON-LD and BBS+ Signatures"
|
||||
layout: single
|
||||
description: An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof
|
||||
excerpt: >
|
||||
BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’06)
|
||||
header:
|
||||
image: "/images/Verifiable-Credentials-Flavors-Explained_JSON-LD_BBSplus.webp"
|
||||
caption: "[[**Verifiable Credentials Flavors Explained**]](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [[**infographic**]](https://www.lfph.io/wp-content/uploads/2021/04/Verifiable-Credentials-Flavors-Explained-Infographic.pdf)"
|
||||
teaser: /images/Verifiable-Credentials-Flavors-Explained_jsonld-lds-teaser.webp
|
||||
tags: ["W3C","Verifiable Credentials","JSON-LD","Data Integrity","BBS"]
|
||||
categories: ["Verifiable Credentials and Decentralized Identifiers"]
|
||||
permalink: /web-standards/w3c/verifiable-credentials/data-integrity-bbs+/
|
||||
last_modified_at: 2023-09-29
|
||||
---
|
||||
|
||||
## Main
|
||||
* [Working Draft] [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) 2023-09-02 - Securing the Integrity of Verifiable Credential Data
|
||||
> This specification describes mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementors of distributed systems.
|
||||
|
||||
## About
|
||||
* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young [Presentation](https://www.slideshare.net/Kaliya/verifiable-credentials-explained-by-cci)
|
||||
> This approach to VCs is innovative because it brings together different elements from several of the existing approaches to VCs. It is based on the usage of [BBS+ JSON-LD Signatures](https://github.com/mattrglobal/jsonld-signatures-bbs), which is a subclass of [LD Signatures](https://w3c-ccg.github.io/ld-proofs/), in combination with a JSON-LD credential schema. The cryptography behind this mechanism is BBS+ Signatures, which require what’s called a [pairing-friendly](https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03) curve. Existing implementations in the VC ecosystem use the elliptic curve [BLS12–381](https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-02#section-2.4)
|
||||
* [BBS+, JSON-LD and Interoperability of Verifiable Credentials](https://medium.com/coinmonks/bbs-json-ld-and-interoperability-of-verifiable-credentials-8bd26b4d3261) 2021-06-20 Coinmonks
|
||||
> In order to request attributes from the credentials JSON-LD frames are used. The credentials and the proofs created by BBS+ signatures are self-describing and do not require a ledger(unlike CL signature based systems like Hyperledger Indy).
|
||||
* [Working Draft] [BBS Cryptosuite v2023 - Securing Verifiable Credentials with Selective Disclosure using BBS Signatures](https://www.w3.org/TR/vc-di-bbs/) 2023-05-24 W3C
|
||||
> This specification defines a set of cryptographic suites for the purpose of creating, verifying and deriving proofs for BBS+ Signatures in conformance with the Data Integrity [VC-DATA-INTEGRITY] specification.
|
||||
>
|
||||
> In general the suites uses the RDF Dataset Normalization Algorithm [RDF-DATASET-NORMALIZATION] to transform an input document into its canonical form. It then uses the statement digest algorithm to digest each statement to be signed individually, finally the digested statements are signed using the defined signature algorithm.
|
||||
>
|
||||
> BBS+ signatures [CFRG-BBS-SIGNATURE] are compatible with any pairing friendly elliptic curve, however the cryptographic suites defined in this document elect to only allow the usage of the BLS12-381 for interoperability purposes.
|
||||
* [Literature] [Revisiting BBS Signatures](https://eprint.iacr.org/2023/275.pdf) 2023, Stefano Tessaro and Chenzhi Zhu
|
||||
> BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’06), and is currently the object of a standardization effort which has led to a recent RFC draft. BBS+ signatures are suitable for use within anonymous credential and DAA systems, as their algebraic structure enables efficient proofs of knowledge of message-signature pairs that support partial disclosure.
|
||||
>
|
||||
> BBS+ signatures consist of one group element and two scalars. As our first contribution, we prove that a variant of BBS+ producing shorter signatures, consisting only of one group element and one scalar, is also secure. The resulting scheme is essentially the original BBS proposal, which was lacking a proof of security. Here we show it satisfies, under the q-SDH assumption, the same provable security guarantees as BBS+. We also provide a complementary tight analysis in the algebraic group model, which heuristically justifies instantiations with potentially shorter signatures.
|
||||
* [JWT; BBS+; Data Integrity] [Formalising Linked-Data based Verifiable Credentials for Selective Disclosure](https://ssr2022.com/slides/FormalisingLinkedDataBasedVerifiableCredentials.pdf) 2022 Dan Yamamoto, Yuji Suga, Kazue Sako IEEE
|
||||
> 
|
||||
* [SSI Essentials: Zero Knowledge Proof (ZKP) and Selective Disclosure, till death do us part?](https://gataca.io/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/) 2022-01-23 Gataca
|
||||
> Selective disclosure via BBS+ signatures [...]
|
||||
>
|
||||
> Like monoclaim credentials allow users to share specific claims from a VC, BBS+ Signatures is a multi-message digital signature scheme (named after its creators Boneh, Boyen, and Shacham) that gives users the possibility of sharing VCs with only specific attributes revealed. How does it work?
|
||||
>
|
||||
> BBS+ signatures allow a VC holder to derive proofs from the original signature:
|
||||
> - Deriving a proof: When a holder takes the signed VC and hides one, several, or none of the containing claims, creating a new signature (a derived proof) using the Issuer's public key. This derived proof can prove that the holder knows all of the original claims contained in the VC but chooses only to reveal the required ones.
|
||||
> - Verifying a proof: The verifier validates the derived proof using the Issuer's public key. This process enables the verifier to confirm the validity of the proof, proving that the subset of claims was part of an original message signed by the Issuer.
|
||||
* [Why the Verifiable Credentials Community Should Converge on BBS+](https://www.evernym.com/blog/bbs-verifiable-credentials/) 2021-03-24 Evernym
|
||||
> BBS+ LD-Proofs use JSON-LD schemas, so credentials that use them can have a rich, hierarchical set of attributes. Instead of the heavy-handed mechanism for the encoding and canonicalization of attributes values that we’d imagined for Rich Schemas, they use RDF canonicalization and a hash function. Rather than expanding the credential definition, they discarded it, taking advantage of some properties of BBS+ keys which allow for deterministic expansion.
|
||||
|
||||
### Development
|
||||
* [Code] [jsonld-signatures-bbs](https://www.npmjs.com/package/@mattrglobal/jsonld-signatures-bbs) 2022-12-18 Mattr Global, NPMJS
|
||||
> The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.
|
||||
>
|
||||
> Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.
|
||||
* [GitHub] [bbs-signatures](https://github.com/mattrglobal/bbs-signatures) 2022-12-21 Mattr Global
|
||||
> BBS+ Signatures are a digital signature algorithm originally born from the work on Short group signatures by Boneh, Boyen, and Shachum which was later improved on in Constant-Size Dynamic k-TAA as BBS+ and touched on again in section 4.3 in Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited .
|
||||
>
|
||||
> BBS+ signatures require a pairing-friendly curve, this library includes support for BLS12-381.
|
||||
>
|
||||
> BBS+ Signatures allow for multi-message signing whilst producing a single output signature. With a BBS signature, a proof of knowledge based proof can be produced where only some of the originally signed messages are revealed at the discretion of the prover.
|
||||
* [GitHub] [jsonld-signatures-bbs](https://github.com/mattrglobal/jsonld-signatures-bbs) Mattr Global
|
||||
> The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.
|
||||
>
|
||||
> Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.
|
||||
>
|
||||
> This library is runnable in browser and Node.js through the WASM based crypto implementation provided by bbs-signatures. Note bbs-signatures also has an optional dependency on node-bbs-signatures which can be used when running in Node.JS environments to obtain better performance. For environments that do not feature WASM support such as react native, bbs-signatures includes an automatic roll back to an asm.js version but note however the performance difference between asm.js and WASM is significant, for those inclined there are runnable benchmarks in bbs-signatures.
|
||||
* [GitHub] [jsonld-signatures-bbs](https://github.com/zkp-ld/jsonld-signatures-bbs) 2023-02-23 ZKP-LD
|
||||
> Experimental: do not use in production
|
||||
> - Based on MATTR's jsonld-signatures-bbs
|
||||
> - Supports termwise selective disclosure, proof of termwise equality, and credential aggregation
|
||||
> - dependencies upgraded
|
||||
> - WASM only; Neon is currently not supported
|
||||
* [GitHub] [bbs-signatures](https://github.com/zkp-ld/bbs-signatures) ZKP-LD
|
||||
> Experimental: do not use in production
|
||||
> - Based on MATTR's bbs-signatures
|
||||
> - Supports termwise selective disclosure, proof of termwise equality, and credential aggregation
|
||||
> - WASM only; Neon is currently not supported
|
||||
* [Implement Compound Proof BBS+ verifiable credentials using ASP.NET Core and MATTR](https://damienbod.com/2021/12/13/implement-compound-proof-bbs-verifiable-credentials-using-asp-net-core-and-mattr/) 2021-12-13 damienbod
|
||||
> This article shows how Zero Knowledge Proofs BBS+ verifiable credentials can be used to verify credential subject data from two separate verifiable credentials implemented in ASP.NET Core and MATTR. The ZKP BBS+ verifiable credentials are issued and stored on a digital wallet using a Self-Issued Identity Provider (SIOP) and OpenID Connect. A compound proof presentation template is created to verify the user data in a single verify.
|
||||
>
|
||||
> Code: https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 322 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 323 KiB |
BIN
images/Verifiable-Credentials-Flavors-Explained_jsonld-bbs-teaser.webp
Executable file
BIN
images/Verifiable-Credentials-Flavors-Explained_jsonld-bbs-teaser.webp
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Loading…
Reference in New Issue
Block a user