add excerpt

_posts/decentralized-web/2021-04-14-iota.md

@@ -9,7 +9,7 @@ excerpt: >
 layout: single
 permalink: blockchain/iota-foundation/
 canonical_url: 'https://decentralized-id.com/blockchain/iota-foundation/'
-category: ["Decentralized We"]
+category: ["Decentralized Web"]
 tags: ["IOTA","Blockchain","Dark Matter Labs","Eclipse"]
 header:
   image: /images/iota-identity.webp

_posts/web-standards/DIDs-and-VCs/2023-06-12-anoncreds.md

@@ -5,7 +5,7 @@ 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"]
+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

_posts/web-standards/DIDs-and-VCs/2023-09-08-VC-JSON-LD_Data-Integrity.md

@@ -0,0 +1,135 @@
+---
+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

_posts/web-standards/DIDs-and-VCs/2023-09-08-VC-ZKP-CL.md

@@ -0,0 +1,33 @@
+---
+title: "Verifiable Credentials (ZKP-CL) Anoncreds"
+layout: single
+description: ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL)
+excerpt: >
+  This credential format was created specifically to leverage the CL Signatures. 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
+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"]
+categories: ["Verifiable Credentials and Decentralized Identifiers"]
+permalink: /web-standards/w3c/verifiable-credentials/zkp-cl/
+last_modified_at: 2023-09-13
+---
+
+* [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
+  > 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
+  > 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

_posts/web-standards/DIDs-and-VCs/2023-09-08-VC_JOSE-COSE.md

@@ -0,0 +1,126 @@
+---
+title: "Verifiable Credentials with JOSE (JWT) / COSE (CBOR)"
+layout: single
+description: "enables the Verifiable Credential data model [VC-DATA-MODEL] to be implemented with standards for signing and encryption that are widely adopted."
+excerpt: >
+  Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key holder), are an essential part of processing a verifiable credential.
+tags: ["W3C","Verifiable Credentials","JWT","IANA","JOSE","COSE"]
+categories: ["Verifiable Credentials and Decentralized Identifiers"]
+permalink: /web-standards/w3c/verifiable-credentials/jose-jwt+cose-cbor/
+header:
+  image: /images/Verifiable-Credentials-Flavors-Explained_jwt.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_jwt-teaser.webp
+last_modified_at: 2023-09-09
+---
+
+## Main
+* [Working Draft] [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/) 2023-09-08 Orie Steele, Michael Jones, Michael Prorock
+  >  This specification defines how to secure credentials and presentations conforming to the [VC-DATA-MODEL](https://www.w3.org/TR/vc-jose-cose/#bib-vc-data-model), with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption ([COSE](https://datatracker.ietf.org/wg/jose/about/)) [RFC9052](https://www.w3.org/TR/vc-jose-cose/#bib-rfc9052). This enables the Verifiable Credential data model [VC-DATA-MODEL] to be implemented with standards for signing and encryption that are widely adopted. 
+* [Native JWT Representation for Verifiable Credentials](https://self-issued.info/?p=2316) 2023-02-10 Mike Jones
+  > For the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable. 
+* [Editors Draft] [Verifiable Credentials Data Model v2.0](https://w3c.github.io/vc-data-model/) 2023-09-09
+  > Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key holder), are an essential part of processing a verifiable credential. At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms:
+  > - Securing Verifiable Credentials using JOSE and COSE [[VC-JOSE-COSE](https://w3c.github.io/vc-data-model/#bib-vc-jose-cose)].
+  > - Securing Verifiable Credentials using Data Integrity Proofs [[VC-DATA-INTEGRITY](https://w3c.github.io/vc-data-model/#bib-vc-jose-cose)].
+  > - Camenisch-Lysyanskaya Zero-Knowledge Proofs [[CL-SIGNATURES](https://w3c.github.io/vc-data-model/#bib-cl-signatures)].
+* [Misinformation Stops Here: W3C VC 2.0 Supports JSON](https://identitywoman.net/misinformation-stops-here-w3c-vc-2-0-supports-json/) 2023-07-21 Kaliya Young 
+  > There is one “extra” field that JSON-LD requires/needs which is @context and if you didn’t want to use it and simply wanted to ignore it and just do JSON you could. The VC would be entirely compliant and thus both data expression formats could live in the same specification. JSON-LD credentials that did have an @context that were being read by tooling that just did JSON could still read the credentials – it did nothing to interfere. This seems like a pretty good “let’s figure out how to live with each other” solution. 
+* [Draft] [JSON Web Proof](https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof-00.html) 2022-07-24 IETF
+  > This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.
+* [JSON Web Proof (JWP)](https://hackmd.io/@quartzjer/JSON_Web_Proof) 2021-06-29 QuartzJer
+  > A JSON Web Proof (JWP) is very similar to a JWS, with the addition that it can contain multiple individual payloads instead of a singular one. New JWP-supporting algorithms are then able to separate and act on the individual payloads contained within.
+
+## Verifiable Credentials with JSON Web Token (JOSE)
+* [Verifiable Credentials Deep Dive](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/decentralized-identity-verifiable-credentials-deep-dive/ba-p/3690641) 2022-12-09 Pamela Dingle, Microsoft
+  > A JWT-VC has three parts, and the payload contains what I would call envelope information: the data needed to know who the credential is is bound to, who made the credential, when it was made and how it can be identified.  Additionally, there is a JSON object called “vc”. Claims information is embedded inside the vc object.  A JWT-VC uses an external proof, meaning in this case that signature data is not embedded inline with the credential, the signature is detached from the credential. 
+  > ![](https://i.imgur.com/ZBlDL7f.png)
+* [Verifiable Credentials Flavors Explained](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) 2021 CCI Kaliya 'Identity Woman' Young
+  > JWT takes a different approach to determining the meaning of claim terms in credentials. There is an [IANA registry for JWT claims](https://www.iana.org/assignments/jwt/jwt.xhtml) as a first place to look for JWT claim definitions. If the claim name isn’t in the IANA register, then the claim can be given a “give it a public name (i.e., a URI), [or] a local name (i.e., any string)”. The meaning of the terms is decided between the issuers and verifiers.
+  > 
+  > 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).
+* [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
+  > JWTs have the benefit of already being widely used in today’s identity technologies, most notably in the framework used by OAuth 2.0 and OpenID Connect. Because of this, there are a number of existing software libraries and tools that developers can use immediately to begin building out their implementations. In addition, due to the fact that JWT-based credentials rely on a shared assertion format with existing identity technologies, it may be an easier mental model for newcomers to adopt when starting to experiment with VCs.
+
+### VC-JWT Selective Disclosure
+* [Standards Track] [SD-JWT-based Verifiable Credentials (SD-JWT VC)](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) 2023-08-16 Oliver Terbu, Daniel Fett IETF 
+  > JSON Web Tokens (JWTs) [RFC7519] can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.
+  > 
+  > Selective Disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).
+  > 
+  > SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures. However, SD-JWT itself does not define the claims that must be used within the payload or their semantics.
+  > 
+  > This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload. Those Verifiable Credentials are called SD-JWT VCs.
+* [Selective Disclosure with SD-JWT](https://api-pilot.ebsi.eu/docs/specs/guidelines/selective-disclosure-sd-jwt) 2023
+  > The purpose of this guideline is to document how to use SD-JWT with both versions V1.1 and V2.0 of the W3C Verifiable Credentials Data Model (VCDM). The document also covers application of these models in either JSON or JSON-LD format, and methods for protecting them using JWS signatures (compact or JSON serialised).
+
+### VC-JWT Presentation
+* [JWT VC Presentation Profile](https://identity.foundation/jwt-vc-presentation-profile/) 2023-08-07 DIF
+  > The JWT VC Presentation Profile defines a set of requirements against existing specifications to enable the interoperable presentation of Verifiable Credentials (VCs) between Wallets and Verifiers.
+  > 
+  > This document is not a specification, but a profile. It outlines existing specifications required for implementations to interoperate among each other. It also clarifies mandatory to implement features for the optionalities mentioned in the referenced specifications.
+  > 
+  > The profile uses OpenID for Verifiable Presentations (OpenID4VP ID1) as the base protocol for the request and verification of W3C JWT VCs as W3C Verifiable Presentations (VC Data Model v1.1).
+* [MDL, JWT-VC, LD-Proofs] [OpenID for Verifiable Presentations](https://openid.net/specs/openid-4-verifiable-presentations-1_0-14.html) 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.
+* [Let’s (actually) Share Our Verifiable Credentials - Introducing the JWT VC Presentation Profile](https://medium.com/workday-engineering/lets-actually-share-our-verifiable-credentials-7ab1b4c73079) 2022-07-25 Jen Schreiber, Workday Technology
+  > In order to tackle the problem of how we actually share credentials, Workday teamed up with Microsoft, Ping Identity, and MATTR to develop a [specification profile](https://identity.foundation/jwt-vc-presentation-profile) that outlines a list of standards and, once adopted by providers, would enable seamless verification of VCs. Development of the profile continues within the Decentralized Identity Foundation (DIF).
+  > 
+  > In this blog post, we will give an overview of why specification profiles are required, what this profile involves, and what it means for the adoption of VCs.
+
+### VC-JWT Development
+* [GitHub, NPM] [did-jwt-vc](https://github.com/decentralized-identity/did-jwt-vc) 2023-09-04 DIF
+  > Create and verify W3C Verifiable Credentials and Presentations in JWT format
+* [Web Tool] [Transmute JSON Web Tokens into Verifiable Credentials](https://jwt.vc/)
+  > Encoded PASTE A TOKEN HERE
+* [Web Tool] [JWT VC Interop Profile](https://vcinteroptesting.azurewebsites.net/) Microsoft
+  > Verifiable Credential Issuance and Verifier Sample
+* [Web Tool] [VC validator](https://api-pilot.ebsi.eu/docs/tools/vc-validator) EBSI
+  > Validate a Verifiable Credential (VC) or a Verifiable Presentation (VP) using the [@cef-ebsi/verifiable-credential](https://api-pilot.ebsi.eu/docs/libraries/verifiable-credential) and [@cef-ebsi/verifiable-presentation](https://api-pilot.ebsi.eu/docs/libraries/verifiable-presentation) libraries.
+* [Spec v3] [Open Badges Specification - JSON Web Token Proof Format](https://www.imsglobal.org/spec/ob/v3p0#jwt-proof) 2023-09-08 Open Badges, IMS Global
+  > This proof format relies on the well established JWT (JSON Web Token) [RFC7519] and JWS (JSON Web Signature) [RFC7515] specifications. A JSON Web Token Proof is a JWT signed and encoded as a Compact JWS string. The proof format is described in detail in Section 6.3.1 "JSON Web Token" of Verifiable Credentials Data Model v1.1. That description allows several options which may inhibit interoperability. This specification limits the options while maintaining compatibility with [VC-DATA-MODEL] to help ensure interoperability.
+* [GitHub] [sd_jwt](https://github.com/kushaldas/sd_jwt) 2022-06-12 Kushaldas
+  > This is an implementation of the SD-JWT draft, revision 2.\
+  > Do not use it in production yet.
+* [GitHub] [kotlin-did-jwt](https://github.com/uport-project/kotlin-did-jwt) 2020-03-21 uPort Project
+  > The kotlin-did-JWT library allows you to sign and verify JSON Web Tokens (JWT) using ES256K, and ES256K-R algorithms.
+
+## Verifiable Credentials with Concise Binary Object Representation (COSE)
+
+* [Unofficial Draft] [Verifiable Credentials with CBOR Object Signatures](https://transmute-industries.github.io/vc-cose/) 2023-01-18 Transmute
+  > This specification introduces a (Content Type) Header Parameter that is used to define the content type for Verifiable Credentials that utilize CBOR Object Signing to provide signing and verification in a Verifiable Credential.
+  > 
+  > This approach, of utilizing to a (Content Type) Header Parameter to specify a discrete set of mappings and expected behaviors in translation between formats or representations of data is used commonly in other groups to secure arbitrary content using COSE and other document and data encoding formats. This approach is extensible to other data encodings and may be extended to provide a mechanism for use of CBOR encodings for Verifiable Credentials. 
+
+### CBOR Explainer
+* [Why CBOR?](https://www.blockchaincommons.com/introduction/Why-CBOR/) 2022-12-07 Blockchain Commons
+  > we have decided to use the IETF CBOR (Concise Binary Object Representation) standard in our specifications, including Gordian Envelope.
+  > 
+  > We chose CBOR as our serialization format choice for several key reasons
+* [Working Group] [Concise Binary Object Representation Maintenance and Extensions (cbor)](https://datatracker.ietf.org/wg/cbor/about/) 2023-06-07
+  > Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format.
+* [W3C Editor's Draft] [CBOR-LD 1.0 - A CBOR-based Serialization for Linked Data](https://digitalbazaar.github.io/cbor-ld-spec/) 2022-09-06 Digital Bazaar, 
+  > CBOR is a compact binary data serialization and messaging format. This specification defines CBOR-LD 1.0, a CBOR-based format to serialize Linked Data. The encoding is designed to leverage the existing JSON-LD ecosystem, which is deployed on hundreds of millions of systems today, to provide a compact serialization format for those seeking efficient encoding schemes for Linked Data. By utilizing semantic compression schemes, compression ratios in excess of 60% better than generalized compression schemes are possible. This format is primarily intended to be a way to use Linked Data in storage and bandwidth constrained programming environments, to build interoperable semantic wire-level protocols, and to efficiently store Linked Data in CBOR-based storage engines. 
+* [RFC 9052] [CBOR Object Signing and Encryption (COSE): Structures and Process](https://www.rfc-editor.org/rfc/rfc9052) 2022-08
+  > Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
+* [RFC 9053] [CBOR Object Signing and Encryption (COSE): Initial Algorithms](https://www.rfc-editor.org/rfc/rfc9053)
+  > Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).
+* [Compact Credentials](https://learn.mattr.global/docs/vii-platform/compact-credentials/) Mattr
+  > CBOR is a binary data format derived from JSON that allows it to utilizes data types like numbers, strings & arrays, however, due to being binary, it offers a much more compact message size. Often when CBOR is being discussed or documented, we can represent the data model using JSON to simplify the way the data can be viewed and modelled. 
+
+### VC-CBOR Development
+
+* ["mDL","eID"] [The Developers’ Dilemma (why mdoc credentials)](https://walt.id/blog/p/mdl-eid-and-beyond) 2023-08-11 WaltID
+  > Though, as it is with many new technologies. Before they can reach the masses, they share a common trait: building with them is challenging and time-consuming, which is based on the lack of developer tools making usage easy and implementation quick.
+  > 
+  > Which is why we build the [mdoc lib](https://github.com/walt-id/waltid-mdoc), as an addition to our open-source identity stack. Proving our commitment to deliver on the latest developments in the industry. Offering tools that let you build compliant solutions across identity ecosystems using different identity flavors with ease, whether that be on- or off-chain identity like Tokens/NFTs,  W3C Verifiable Credentials or now mdoc credentials. mdoc is a binary highly storage efficient credential format leveraging CBOR, standardized through ISO/IEC 18013-5:2021 mDL specification. 
+* [@mattrglobal/vc-cwt-verifier](https://www.npmjs.com/package/@mattrglobal/vc-cwt-verifier) NPMJS
+  - Verify a credential
+  - Verify a credential with a list of trusted issuers
+  - Verify a credential skipping expiry and not before checks
+  - Provide custom cache for issuer resolution