Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-12-25 07:09:33 -05:00
Code Issues Packages Projects Releases Wiki Activity

cleanup

Browse Source
This commit is contained in:
⧉ infominer 2023-09-10 17:17:35 -04:00
parent f4dbf54494
commit edf78de2d2
1 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
_data/standards.csv
View File

@ -48,11 +48,6 @@ 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,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",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, 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,LPFH,,,Kaliya IdentityWoman,,,,,,Verifiable Credentials Flavors Explained,"Below are the three primary flavors of VCs discussed in this paper. All have more than one critical implementation in various stages of production. There are advocated variations of these types, but they are less common.<br>* JSON-LD family with LD Signatures or with BBS+ Signatures that enable Zero Knowledge Proofs (ZKP or ZKPs)<br>* JSON with JSON Web Signatures, precisely in the form of a JSON Web Token (JWT)<br>* ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL)",,https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf,,Post,,,Varieties,,,,,,,,2021-02,,,,,,,,,,,,,
"Standards, Verifiable Credentials",LFPH,,https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf,Lucy Yang,,,,,,The Flavors of Verifiable Credentials,The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’.,,https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/,,Paper,,,"Varieties, Decentralized Identity Stack",,,,,,,,2021-11-11,,,,,,,,,,,,,
Verifiable Credentials,Evernym,,,Daniel Hardman,,,,,,Categorizing Verifiable Credentials - Evernym,Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation.,Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation.,https://www.evernym.com/blog/categorizing-verifiable-credentials/,,Post,,,Varieties,,,,,,,,2019-11-07,,,,,,,,,,,,,
Verifiable Credentials,Evernym,,,Brent Zundel,,,,,,Why the Verifiable Credentials Community Should Converge on BBS+,"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.",BBS+ ZKP signatures: The breakthrough the industry has been looking for to converge on a universal format for privacy-respecting VCs.,https://www.evernym.com/blog/bbs-verifiable-credentials/,,Post,,,Varieties,,,,,,,,2021-03-24,,,,,,,,,,,,,
Verifiable Credentials,Personal,,,Steve Lockstep,,,,,,The original #VerifiableCredentials were PKI-based SIM cards and EMV cards.,"These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. [https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little](https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little)<br>$5",,https://twitter.com/Steve_Lockstep/status/1419935186188341249,https://i.imgur.com/ucAVxCX.png,tweet,,,Varieties,,,,,,,,2021-06-27,,,,,,,,,,,,,
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,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,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,,,,,,,,,,,,, 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,,,,,,,,,,,,,
@ -125,6 +120,10 @@ VCs Development,CCG Mailing List,,,Bob Wyman,,,,,,Any Good use case of PAM (Priv
VCs Development,Mattr,,,,,,,,,Paper based Verifiable Credentials,Paper-based Verifiable Credentials allow us to have a low-tech solution for adopting VC's in situations where access to a phone cannot be guaranteed. This presentation looks at how this solution can be used to aid with the distribution of Vaccine Credentials.,Paper-based verifiable credentials allow us to have a low-tech solution for adopting verifiable credential's in situations where access to a phone cannot be ...,https://www.youtube.com/watch?v=EXvWxFjHvdY,,Video,,,Development,,,,,,,,2021-03-02,,,,,,,,,,,,, VCs Development,Mattr,,,,,,,,,Paper based Verifiable Credentials,Paper-based Verifiable Credentials allow us to have a low-tech solution for adopting VC's in situations where access to a phone cannot be guaranteed. This presentation looks at how this solution can be used to aid with the distribution of Vaccine Credentials.,Paper-based verifiable credentials allow us to have a low-tech solution for adopting verifiable credential's in situations where access to a phone cannot be ...,https://www.youtube.com/watch?v=EXvWxFjHvdY,,Video,,,Development,,,,,,,,2021-03-02,,,,,,,,,,,,,
VCs Development,Trusted Digital Web,,,,,,,,,Using Paper-based Structured Credentials to Humanize Verifiable Credentials,User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages. Michael Herman,User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages.This tutorial was inspired by...,https://www.youtube.com/watch?v=kM30pd3w8qE,,Video,Rough Cut,,User Experience,,,,,,,,2021-11-19,,,,,,,,,,,,, VCs Development,Trusted Digital Web,,,,,,,,,Using Paper-based Structured Credentials to Humanize Verifiable Credentials,User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages. Michael Herman,User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages.This tutorial was inspired by...,https://www.youtube.com/watch?v=kM30pd3w8qE,,Video,Rough Cut,,User Experience,,,,,,,,2021-11-19,,,,,,,,,,,,,
VCs Development,WebofTrustInfo,,,Manu Sporny,,,,,RWoT,Rendering Verifiable Credentials,"This paper explores ways in which the Verifiable Credentials data model could be extended to support visual, audio, and physical renderings for Verifiable Credentials.",,https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md,,Paper,,,User Experience,,,,,,,,2022-07-17,,,,,,,,,,,,, VCs Development,WebofTrustInfo,,,Manu Sporny,,,,,RWoT,Rendering Verifiable Credentials,"This paper explores ways in which the Verifiable Credentials data model could be extended to support visual, audio, and physical renderings for Verifiable Credentials.",,https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md,,Paper,,,User Experience,,,,,,,,2022-07-17,,,,,,,,,,,,,
"Standards, VCs Development",LPFH,,https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/,"Kaliya IdentityWoman, Lucy Yang",,,,,,Verifiable Credentials Flavors Explained,"Below are the three primary flavors of VCs discussed in this paper. All have more than one critical implementation in various stages of production. There are advocated variations of these types, but they are less common.<br>* JSON-LD family with LD Signatures or with BBS+ Signatures that enable Zero Knowledge Proofs (ZKP or ZKPs)<br>* JSON with JSON Web Signatures, precisely in the form of a JSON Web Token (JWT)<br>* ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL)",The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’.,https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf,,Paper,,,"Varieties, Decentralized Identity Stack",,,,,,,,2021-02-11,,,,,,,,,,,,,
VCs Development,Evernym,,,Daniel Hardman,,,,,,Categorizing Verifiable Credentials - Evernym,Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation.,Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation.,https://www.evernym.com/blog/categorizing-verifiable-credentials/,,Post,,,Varieties,,,,,,,,2019-11-07,,,,,,,,,,,,,
VCs Development,Evernym,,,Brent Zundel,,,,,,Why the Verifiable Credentials Community Should Converge on BBS+,"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.",BBS+ ZKP signatures: The breakthrough the industry has been looking for to converge on a universal format for privacy-respecting VCs.,https://www.evernym.com/blog/bbs-verifiable-credentials/,,Post,,,Varieties,,,,,,,,2021-03-24,,,,,,,,,,,,,
VCs Development,Personal,,,Steve Lockstep,,,,,,The original #VerifiableCredentials were PKI-based SIM cards and EMV cards.,"These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. [https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little](https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little)<br>$5",,https://twitter.com/Steve_Lockstep/status/1419935186188341249,https://i.imgur.com/ucAVxCX.png,tweet,,,Varieties,,,,,,,,2021-06-27,,,,,,,,,,,,,
Decentralized Identifiers,CCG,,,,,,,,,A Primer for Decentralized Identifiers,An introduction to self-administered identifiers for curious people,"A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolvable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. This document is an introduction to the concept of Decentralized Identifiers.",https://w3c-ccg.github.io/did-primer/,https://w3c-ccg.github.io/did-primer/did-primer-diagrams/urn-format.png,Report,,,Main,,,,,,,Credentials Community Group,2021-11-11,https://github.com/w3c-ccg/did-primer,,,,,,,,,,,, Decentralized Identifiers,CCG,,,,,,,,,A Primer for Decentralized Identifiers,An introduction to self-administered identifiers for curious people,"A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolvable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. This document is an introduction to the concept of Decentralized Identifiers.",https://w3c-ccg.github.io/did-primer/,https://w3c-ccg.github.io/did-primer/did-primer-diagrams/urn-format.png,Report,,,Main,,,,,,,Credentials Community Group,2021-11-11,https://github.com/w3c-ccg/did-primer,,,,,,,,,,,,
Decentralized Identifiers,W3C,,,Markus Sabadello,"Danube Tech, Sovrin Foundation, OASIS XDI TC",Vienna,,,W3C Workshop on Privacy and Linked Data,Decentralized IDentifers (DIDs),"- Developed at Rebooting-the-Web-of-Trust workshop and W3C Credentials CG<br>- Persistent, dereference-able, cryptographically verifable identifers<br>- Registered in a blockchain or other decentralized network",,https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf,https://i.imgur.com/7NRcJbq.png,Presentation,,,Main,,,,,,,,2018-04-17,,,,,,,,,,,,, Decentralized Identifiers,W3C,,,Markus Sabadello,"Danube Tech, Sovrin Foundation, OASIS XDI TC",Vienna,,,W3C Workshop on Privacy and Linked Data,Decentralized IDentifers (DIDs),"- Developed at Rebooting-the-Web-of-Trust workshop and W3C Credentials CG<br>- Persistent, dereference-able, cryptographically verifable identifers<br>- Registered in a blockchain or other decentralized network",,https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf,https://i.imgur.com/7NRcJbq.png,Presentation,,,Main,,,,,,,,2018-04-17,,,,,,,,,,,,,
Decentralized Identifiers,Identity Foundation,,,,,,,,,Decentralized Identifiers (DID) 1.0 specification approved as W3C Recommendation,"Announcing the [Decentralized Identifiers (DID) v1.0 specification](https://www.w3.org/TR/did-core/) as an open web standard signals that it is technically sound, mature, and ready for widespread adoption. Having an established v1.0 specification allows work to continue with renewed energy and focus, not only at the many groups meeting at DIF, but across the digital identity community.",The W3C has approved the DIDCore V1.0 spec as an official Recommentdation; DIDs are now an open web standard ready for use and further development,https://blog.identity.foundation/w3cdidspec-2/,,Post,,,Main,,,,,,,,2022-06-22,,,,,,,,,,,,, Decentralized Identifiers,Identity Foundation,,,,,,,,,Decentralized Identifiers (DID) 1.0 specification approved as W3C Recommendation,"Announcing the [Decentralized Identifiers (DID) v1.0 specification](https://www.w3.org/TR/did-core/) as an open web standard signals that it is technically sound, mature, and ready for widespread adoption. Having an established v1.0 specification allows work to continue with renewed energy and focus, not only at the many groups meeting at DIF, but across the digital identity community.",The W3C has approved the DIDCore V1.0 spec as an official Recommentdation; DIDs are now an open web standard ready for use and further development,https://blog.identity.foundation/w3cdidspec-2/,,Post,,,Main,,,,,,,,2022-06-22,,,,,,,,,,,,,
@ -481,9 +480,8 @@ Linked Data,WebofTrustInfo,,,"Manu Sporny, Harlan Wood, Noah Thorp, Wayne Vaughn
Linked Data,WebofTrustInfo,,,"Ganesh Annan, Kim Hamilton Duffy",,,,,rwot7-toronto,Resource Integrity Proofs,"Cryptographic linking provides discoverability, integrity, and scheme agility<br>Contributors: Manu Sporny, Dave Longley, David Lehn, and Bohdan Andriyiv<br>Currently, the Web provides a simple yet powerful mechanism for the dissemination of information via links. Unfortunately, there is no generalized mechanism that enables verifying that a fetched resource has been delivered without unexpected manipulation. Would it be possible to create an extensible and multipurpose cryptographic link that provides discoverability, integrity, and scheme agility?<br>Cryptographic linking solutions today have yet to provide a generalized mechanism for creating tamper-evident links. The Subresource Integrity standard limits this guarantee to script and link resources loaded on Web pages via the use of HTML attributes. IPFS provides a verification mechanism that is constrained to hash-based, content-addressable links, with no ability to complete content negotiation. RFC6920 proposes another mechanism that cannot be applied to existing links: it recommends the use of named information hashes and a resolution method that creates a content addressable URL [1]. Resource Integrity Proofs incorporates ideas from these standards and solutions to provide a new data format for cryptographic links that is fit for the open world.",,https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/resource-integrity-proofs.md,,Paper,,,Main,,,,,,,,2018-12-12,,,,,,,,,,,,, Linked Data,WebofTrustInfo,,,"Ganesh Annan, Kim Hamilton Duffy",,,,,rwot7-toronto,Resource Integrity Proofs,"Cryptographic linking provides discoverability, integrity, and scheme agility<br>Contributors: Manu Sporny, Dave Longley, David Lehn, and Bohdan Andriyiv<br>Currently, the Web provides a simple yet powerful mechanism for the dissemination of information via links. Unfortunately, there is no generalized mechanism that enables verifying that a fetched resource has been delivered without unexpected manipulation. Would it be possible to create an extensible and multipurpose cryptographic link that provides discoverability, integrity, and scheme agility?<br>Cryptographic linking solutions today have yet to provide a generalized mechanism for creating tamper-evident links. The Subresource Integrity standard limits this guarantee to script and link resources loaded on Web pages via the use of HTML attributes. IPFS provides a verification mechanism that is constrained to hash-based, content-addressable links, with no ability to complete content negotiation. RFC6920 proposes another mechanism that cannot be applied to existing links: it recommends the use of named information hashes and a resolution method that creates a content addressable URL [1]. Resource Integrity Proofs incorporates ideas from these standards and solutions to provide a new data format for cryptographic links that is fit for the open world.",,https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/resource-integrity-proofs.md,,Paper,,,Main,,,,,,,,2018-12-12,,,,,,,,,,,,,
Linked Data,WebofTrustInfo,,,,,,,,rwot6-santabarbera,Recent happenings with Linked Data Capabilities,"Veres One's architecture has been adjusted to take full advantage of Linked Data Capabilities as its primary mechanism for granting authority to perform operations on the ledger as well as on DID Documents. permission to update key materials can be conditionally handed out to an entity (or entities) and later revoked if deemed appropriate using Linked Data Capabilities' design.<br>As for ledger updates, Accelerators also make use of Linked Data Capabilities. To prevent spamming the ledger, the costs of an update must somehow be accounted for. The traditional way to do this on a blockchain is to use proof of work, and this is also an option in Veres One, but for those use cases where expending time and energy on proof of work is less desirable users can use an ""accelerator"".<br>An accelerator is an entity that has been granted a capability to perform updates on the ledger more quickly. Accelerators may likewise take advantage of Linked Data Capabilities' support for delegation, with or without caveats.",,https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/ld-ocap-recent-happenings.md,,Paper,,,Main,,,,,,,,2018-03-02,,,,,,,,,,,,, Linked Data,WebofTrustInfo,,,,,,,,rwot6-santabarbera,Recent happenings with Linked Data Capabilities,"Veres One's architecture has been adjusted to take full advantage of Linked Data Capabilities as its primary mechanism for granting authority to perform operations on the ledger as well as on DID Documents. permission to update key materials can be conditionally handed out to an entity (or entities) and later revoked if deemed appropriate using Linked Data Capabilities' design.<br>As for ledger updates, Accelerators also make use of Linked Data Capabilities. To prevent spamming the ledger, the costs of an update must somehow be accounted for. The traditional way to do this on a blockchain is to use proof of work, and this is also an option in Veres One, but for those use cases where expending time and energy on proof of work is less desirable users can use an ""accelerator"".<br>An accelerator is an entity that has been granted a capability to perform updates on the ledger more quickly. Accelerators may likewise take advantage of Linked Data Capabilities' support for delegation, with or without caveats.",,https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/ld-ocap-recent-happenings.md,,Paper,,,Main,,,,,,,,2018-03-02,,,,,,,,,,,,,
Linked Data,WebofTrustInfo,,,,,,,,rwot4-paris,LD Signature Format Alignment,"The goal of the ""LD Signature Format Alignment"" Working Group at Rebooting the Web of Trust IV was to investigate the feasibility and impact of the proposed 2017 RSA Signature Suite spec, which brings JSON-LD signatures into alignment with the JOSE JSON Web Signature (JWS) standards.The 2017 RSA Signature Suite is based on RFC 7797, the JSON Web Signature (JWS) Unencoded Payload Option specifcation. This approach avoids past concerns about JWT raised in the LD signature adopters, including:•Increased space consumption associated withbase-64 encoding.•Difculty of nesting or chaining signatures, leading to data duplication.•Use of a format that is not a JSON object, preventing ability to rely exclusively on a JSON document-based storage engine (whilepreserving the signature)",,https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot4-paris/blob/master/final-documents/ld-signatures.pdf,,Paper,,,Main,,,,,,,,2017-08-18,,,,,,,,,,,,, Linked Data,WebofTrustInfo,,,,,,,,rwot4-paris,LD Signature Format Alignment,"The goal of the ""LD Signature Format Alignment"" Working Group at Rebooting the Web of Trust IV was to investigate the feasibility and impact of the proposed 2017 RSA Signature Suite spec, which brings JSON-LD signatures into alignment with the JOSE JSON Web Signature (JWS) standards.The 2017 RSA Signature Suite is based on RFC 7797, the JSON Web Signature (JWS) Unencoded Payload Option specifcation. This approach avoids past concerns about JWT raised in the LD signature adopters, including:•Increased space consumption associated withbase-64 encoding.•Difculty of nesting or chaining signatures, leading to data duplication.•Use of a format that is not a JSON object, preventing ability to rely exclusively on a JSON document-based storage engine (whilepreserving the signature)",,https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot4-paris/blob/master/final-documents/ld-signatures.pdf,,Paper,,,Main,,,,,,,,2017-08-18,,,,,,,,,,,,,
"Linked Data, Object Capabilities",CCG,,,,,,,,,Authorization Capabilities for Linked Data v0.3,"Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. ""Caveats"" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked.",,https://w3c-ccg.github.io/zcap-spec/,,Specification,,,"Main, Literature",,,,,,,Credentials Community Group,2023-01-22,https://github.com/w3c-ccg/zcap-spec,,,,,,,,,,,, "Linked Data, Object Capabilities",CCG,,,,,,,,,Authorization Capabilities for Linked Data v0.3,"Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. ""Caveats"" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked.<br><br>[...] Relationship to Verifiable Credentials [...]<br><br>We seem to be in a conundrum. Claims and credentials are forms of correlation that allow us to reason about an entity in our squishy human world, but are unsafe when used as mechanisms to authorize some event to occur within a system. Capabilities are a safe mechanism to model the flow of authority through a system, but there are times when capabilities have not been granted and we need to make a ""judgement call"" by correlating information about that entity. What should we do?<br><br>To pose the question is to see the answer: the right approach is to use each system for what it does best. Use correlation (Verifiable Credentials) in a reasoning system (most commonly human reasoning) as a path to make judgements about whether to hand an entity a specific set of initial capabilities. Use capabilities (ZCAP-LD) as the mechanism to grant and exercise authority through computing systems. To return to our system administrator example, when Alice applies for the job, she submits a series of credentials about her prior work history and degree, and Eva is able to verify that it is Alice's former employers and university which have made these claims. Deciding that Alice is fit for the job, Eva hands Alice her initial capability which grants her authority to administrate the systems in question (with a caveat that allows Eva to revoke that authority at a future date, if appropriate). Alice uses that capability as the initial entry point into administrating the system. ",,https://w3c-ccg.github.io/zcap-spec/,,Specification,,,"Main, Literature",,,,,,,Credentials Community Group,2023-01-22,https://github.com/w3c-ccg/zcap-spec,,,,,,,,,,,,
Linked Data,WebofTrustInfo,,,,,,,,,Java implementation of Linked Data Signatures,This is an implementation of the following cryptographic suites for Linked Data Proofs:<br>Ed25519Signature2018<br>Ed25519Signature2020<br>EcdsaSecp256k1Signature2019<br>RsaSignature2018<br>JsonWebSignature2020<br>JcsEd25519Signature2020<br>JcsEcdsaSecp256k1Signature2019,,https://github.com/WebOfTrustInfo/ld-signatures-java,,Code,,,Implementation,,,,,,,,2023-05-13,,,,,,,,,,,,, Linked Data,WebofTrustInfo,,,,,,,,,Java implementation of Linked Data Signatures,This is an implementation of the following cryptographic suites for Linked Data Proofs:<br>Ed25519Signature2018<br>Ed25519Signature2020<br>EcdsaSecp256k1Signature2019<br>RsaSignature2018<br>JsonWebSignature2020<br>JcsEd25519Signature2020<br>JcsEcdsaSecp256k1Signature2019,,https://github.com/WebOfTrustInfo/ld-signatures-java,,Code,,,Implementation,,,,,,,,2023-05-13,,,,,,,,,,,,,
Linked Data,WebofTrustInfo,,,,,,,,,JSON-LD Signatures with JSON Web Signatures,"Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. ""Caveats"" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked.",,https://github.com/WebOfTrustInfo/ld-signatures-python,,Code,,,Implementation,,,,,,Object Capabilities,,2017-04-25,,,,,,,,,,,,,
Linked Data,CCG,,,,,,,,,Linked Data Keys Registry,This repository contains the Linked Data Cryptographic Suite Registry which is a list of all known Linked Data cryptographic suites and their current level of maturity.,,https://github.com/w3c-ccg/ld-cryptosuite-registry,,registry,,,Implementation,,,,,,,Credentials Community Group,2020-12-29,,,,,,,,,,,,, Linked Data,CCG,,,,,,,,,Linked Data Keys Registry,This repository contains the Linked Data Cryptographic Suite Registry which is a list of all known Linked Data cryptographic suites and their current level of maturity.,,https://github.com/w3c-ccg/ld-cryptosuite-registry,,registry,,,Implementation,,,,,,,Credentials Community Group,2020-12-29,,,,,,,,,,,,,
Linked Data,DigitalBazaar,,,,,,,,,Linked Data Capabilities reference implementation,JavaScript reference implementation for Authorization Capabilities.,,https://github.com/digitalbazaar/ocapld.js,,Code,,,Implementation,,,,,,,,2023-01-14,,,,,,,,,,,,, Linked Data,DigitalBazaar,,,,,,,,,Linked Data Capabilities reference implementation,JavaScript reference implementation for Authorization Capabilities.,,https://github.com/digitalbazaar/ocapld.js,,Code,,,Implementation,,,,,,,,2023-01-14,,,,,,,,,,,,,
Linked Data,W3C,,,,,,,,,RDF AND JSON-LD UseCases,This wiki page strive to address one of many question about use of RDF vs JSON-LD to store linked data. This page attempts to provide a general introduction of both the technologies and provide suitability analysis of various kind of applications to use either technology.,,https://www.w3.org/2013/dwbp/wiki/RDF_AND_JSON-LD_UseCases,https://www.w3.org/2013/dwbp/wiki/images/thumb/1/17/RDFSerialization-formats.png/800px-RDFSerialization-formats.png,page,,,RDF,,,,,,,,2014-09-15,,,,,,,,,,,,, Linked Data,W3C,,,,,,,,,RDF AND JSON-LD UseCases,This wiki page strive to address one of many question about use of RDF vs JSON-LD to store linked data. This page attempts to provide a general introduction of both the technologies and provide suitability analysis of various kind of applications to use either technology.,,https://www.w3.org/2013/dwbp/wiki/RDF_AND_JSON-LD_UseCases,https://www.w3.org/2013/dwbp/wiki/images/thumb/1/17/RDFSerialization-formats.png/800px-RDFSerialization-formats.png,page,,,RDF,,,,,,,,2014-09-15,,,,,,,,,,,,,

1 main parent name supporting authors related location serving policy event title text description link image type status platform section sector industry market focus projects tech working group date github twitter youtube list feed discord crunchbase linkedin docs devtools app telegram forum
48 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
49 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
50 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 LPFH Kaliya IdentityWoman Verifiable Credentials Flavors Explained Below are the three primary flavors of VCs discussed in this paper. All have more than one critical implementation in various stages of production. There are advocated variations of these types, but they are less common.<br>* JSON-LD family with LD Signatures or with BBS+ Signatures that enable Zero Knowledge Proofs (ZKP or ZKPs)<br>* JSON with JSON Web Signatures, precisely in the form of a JSON Web Token (JWT)<br>* ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL) https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf Post Varieties 2021-02
Standards, Verifiable Credentials LFPH https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf Lucy Yang The Flavors of Verifiable Credentials The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’. https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/ Paper Varieties, Decentralized Identity Stack 2021-11-11
Verifiable Credentials Evernym Daniel Hardman Categorizing Verifiable Credentials - Evernym Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation. Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation. https://www.evernym.com/blog/categorizing-verifiable-credentials/ Post Varieties 2019-11-07
Verifiable Credentials Evernym Brent Zundel Why the Verifiable Credentials Community Should Converge on BBS+ 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. BBS+ ZKP signatures: The breakthrough the industry has been looking for to converge on a universal format for privacy-respecting VCs. https://www.evernym.com/blog/bbs-verifiable-credentials/ Post Varieties 2021-03-24
Verifiable Credentials Personal Steve Lockstep The original #VerifiableCredentials were PKI-based SIM cards and EMV cards. These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. [https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little](https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little)<br>$5 https://twitter.com/Steve_Lockstep/status/1419935186188341249 https://i.imgur.com/ucAVxCX.png tweet Varieties 2021-06-27
51 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
52 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
53 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
120 VCs Development Mattr Paper based Verifiable Credentials Paper-based Verifiable Credentials allow us to have a low-tech solution for adopting VC's in situations where access to a phone cannot be guaranteed. This presentation looks at how this solution can be used to aid with the distribution of Vaccine Credentials. Paper-based verifiable credentials allow us to have a low-tech solution for adopting verifiable credential's in situations where access to a phone cannot be ... https://www.youtube.com/watch?v=EXvWxFjHvdY Video Development 2021-03-02
121 VCs Development Trusted Digital Web Using Paper-based Structured Credentials to Humanize Verifiable Credentials User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages. Michael Herman User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages.This tutorial was inspired by... https://www.youtube.com/watch?v=kM30pd3w8qE Video Rough Cut User Experience 2021-11-19
122 VCs Development WebofTrustInfo Manu Sporny RWoT Rendering Verifiable Credentials This paper explores ways in which the Verifiable Credentials data model could be extended to support visual, audio, and physical renderings for Verifiable Credentials. https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md Paper User Experience 2022-07-17
123 Standards, VCs Development LPFH https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/ Kaliya IdentityWoman, Lucy Yang Verifiable Credentials Flavors Explained Below are the three primary flavors of VCs discussed in this paper. All have more than one critical implementation in various stages of production. There are advocated variations of these types, but they are less common.<br>* JSON-LD family with LD Signatures or with BBS+ Signatures that enable Zero Knowledge Proofs (ZKP or ZKPs)<br>* JSON with JSON Web Signatures, precisely in the form of a JSON Web Token (JWT)<br>* ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL) The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’. https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf Paper Varieties, Decentralized Identity Stack 2021-02-11
124 VCs Development Evernym Daniel Hardman Categorizing Verifiable Credentials - Evernym Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation. Not all verifiable credentials are created the same. This post examines the categories of credentials and the architectural choices driving this variation. https://www.evernym.com/blog/categorizing-verifiable-credentials/ Post Varieties 2019-11-07
125 VCs Development Evernym Brent Zundel Why the Verifiable Credentials Community Should Converge on BBS+ 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. BBS+ ZKP signatures: The breakthrough the industry has been looking for to converge on a universal format for privacy-respecting VCs. https://www.evernym.com/blog/bbs-verifiable-credentials/ Post Varieties 2021-03-24
126 VCs Development Personal Steve Lockstep The original #VerifiableCredentials were PKI-based SIM cards and EMV cards. These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. [https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little](https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little)<br>$5 https://twitter.com/Steve_Lockstep/status/1419935186188341249 https://i.imgur.com/ucAVxCX.png tweet Varieties 2021-06-27
127 Decentralized Identifiers CCG A Primer for Decentralized Identifiers An introduction to self-administered identifiers for curious people A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolvable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. This document is an introduction to the concept of Decentralized Identifiers. https://w3c-ccg.github.io/did-primer/ https://w3c-ccg.github.io/did-primer/did-primer-diagrams/urn-format.png Report Main Credentials Community Group 2021-11-11 https://github.com/w3c-ccg/did-primer
128 Decentralized Identifiers W3C Markus Sabadello Danube Tech, Sovrin Foundation, OASIS XDI TC Vienna W3C Workshop on Privacy and Linked Data Decentralized IDentifers (DIDs) - Developed at Rebooting-the-Web-of-Trust workshop and W3C Credentials CG<br>- Persistent, dereference-able, cryptographically verifable identifers<br>- Registered in a blockchain or other decentralized network https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf https://i.imgur.com/7NRcJbq.png Presentation Main 2018-04-17
129 Decentralized Identifiers Identity Foundation Decentralized Identifiers (DID) 1.0 specification approved as W3C Recommendation Announcing the [Decentralized Identifiers (DID) v1.0 specification](https://www.w3.org/TR/did-core/) as an open web standard signals that it is technically sound, mature, and ready for widespread adoption. Having an established v1.0 specification allows work to continue with renewed energy and focus, not only at the many groups meeting at DIF, but across the digital identity community. The W3C has approved the DIDCore V1.0 spec as an official Recommentdation; DIDs are now an open web standard ready for use and further development https://blog.identity.foundation/w3cdidspec-2/ Post Main 2022-06-22
480 Linked Data WebofTrustInfo Ganesh Annan, Kim Hamilton Duffy rwot7-toronto Resource Integrity Proofs Cryptographic linking provides discoverability, integrity, and scheme agility<br>Contributors: Manu Sporny, Dave Longley, David Lehn, and Bohdan Andriyiv<br>Currently, the Web provides a simple yet powerful mechanism for the dissemination of information via links. Unfortunately, there is no generalized mechanism that enables verifying that a fetched resource has been delivered without unexpected manipulation. Would it be possible to create an extensible and multipurpose cryptographic link that provides discoverability, integrity, and scheme agility?<br>Cryptographic linking solutions today have yet to provide a generalized mechanism for creating tamper-evident links. The Subresource Integrity standard limits this guarantee to script and link resources loaded on Web pages via the use of HTML attributes. IPFS provides a verification mechanism that is constrained to hash-based, content-addressable links, with no ability to complete content negotiation. RFC6920 proposes another mechanism that cannot be applied to existing links: it recommends the use of named information hashes and a resolution method that creates a content addressable URL [1]. Resource Integrity Proofs incorporates ideas from these standards and solutions to provide a new data format for cryptographic links that is fit for the open world. https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/resource-integrity-proofs.md Paper Main 2018-12-12
481 Linked Data WebofTrustInfo rwot6-santabarbera Recent happenings with Linked Data Capabilities Veres One's architecture has been adjusted to take full advantage of Linked Data Capabilities as its primary mechanism for granting authority to perform operations on the ledger as well as on DID Documents. permission to update key materials can be conditionally handed out to an entity (or entities) and later revoked if deemed appropriate using Linked Data Capabilities' design.<br>As for ledger updates, Accelerators also make use of Linked Data Capabilities. To prevent spamming the ledger, the costs of an update must somehow be accounted for. The traditional way to do this on a blockchain is to use proof of work, and this is also an option in Veres One, but for those use cases where expending time and energy on proof of work is less desirable users can use an "accelerator".<br>An accelerator is an entity that has been granted a capability to perform updates on the ledger more quickly. Accelerators may likewise take advantage of Linked Data Capabilities' support for delegation, with or without caveats. https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/ld-ocap-recent-happenings.md Paper Main 2018-03-02
482 Linked Data WebofTrustInfo rwot4-paris LD Signature Format Alignment The goal of the "LD Signature Format Alignment" Working Group at Rebooting the Web of Trust IV was to investigate the feasibility and impact of the proposed 2017 RSA Signature Suite spec, which brings JSON-LD signatures into alignment with the JOSE JSON Web Signature (JWS) standards.The 2017 RSA Signature Suite is based on RFC 7797, the JSON Web Signature (JWS) Unencoded Payload Option specifcation. This approach avoids past concerns about JWT raised in the LD signature adopters, including:•Increased space consumption associated withbase-64 encoding.•Difculty of nesting or chaining signatures, leading to data duplication.•Use of a format that is not a JSON object, preventing ability to rely exclusively on a JSON document-based storage engine (whilepreserving the signature) https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot4-paris/blob/master/final-documents/ld-signatures.pdf Paper Main 2017-08-18
483 Linked Data, Object Capabilities CCG Authorization Capabilities for Linked Data v0.3 Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. "Caveats" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked. Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. "Caveats" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked.<br><br>[...] Relationship to Verifiable Credentials [...]<br><br>We seem to be in a conundrum. Claims and credentials are forms of correlation that allow us to reason about an entity in our squishy human world, but are unsafe when used as mechanisms to authorize some event to occur within a system. Capabilities are a safe mechanism to model the flow of authority through a system, but there are times when capabilities have not been granted and we need to make a "judgement call" by correlating information about that entity. What should we do?<br><br>To pose the question is to see the answer: the right approach is to use each system for what it does best. Use correlation (Verifiable Credentials) in a reasoning system (most commonly human reasoning) as a path to make judgements about whether to hand an entity a specific set of initial capabilities. Use capabilities (ZCAP-LD) as the mechanism to grant and exercise authority through computing systems. To return to our system administrator example, when Alice applies for the job, she submits a series of credentials about her prior work history and degree, and Eva is able to verify that it is Alice's former employers and university which have made these claims. Deciding that Alice is fit for the job, Eva hands Alice her initial capability which grants her authority to administrate the systems in question (with a caveat that allows Eva to revoke that authority at a future date, if appropriate). Alice uses that capability as the initial entry point into administrating the system. https://w3c-ccg.github.io/zcap-spec/ Specification Main, Literature Credentials Community Group 2023-01-22 https://github.com/w3c-ccg/zcap-spec
484 Linked Data WebofTrustInfo Java implementation of Linked Data Signatures This is an implementation of the following cryptographic suites for Linked Data Proofs:<br>Ed25519Signature2018<br>Ed25519Signature2020<br>EcdsaSecp256k1Signature2019<br>RsaSignature2018<br>JsonWebSignature2020<br>JcsEd25519Signature2020<br>JcsEcdsaSecp256k1Signature2019 https://github.com/WebOfTrustInfo/ld-signatures-java Code Implementation 2023-05-13
Linked Data WebofTrustInfo JSON-LD Signatures with JSON Web Signatures Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. "Caveats" may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked. https://github.com/WebOfTrustInfo/ld-signatures-python Code Implementation Object Capabilities 2017-04-25
485 Linked Data CCG Linked Data Keys Registry This repository contains the Linked Data Cryptographic Suite Registry which is a list of all known Linked Data cryptographic suites and their current level of maturity. https://github.com/w3c-ccg/ld-cryptosuite-registry registry Implementation Credentials Community Group 2020-12-29
486 Linked Data DigitalBazaar Linked Data Capabilities reference implementation JavaScript reference implementation for Authorization Capabilities. https://github.com/digitalbazaar/ocapld.js Code Implementation 2023-01-14
487 Linked Data W3C RDF AND JSON-LD UseCases This wiki page strive to address one of many question about use of RDF vs JSON-LD to store linked data. This page attempts to provide a general introduction of both the technologies and provide suitability analysis of various kind of applications to use either technology. https://www.w3.org/2013/dwbp/wiki/RDF_AND_JSON-LD_UseCases https://www.w3.org/2013/dwbp/wiki/images/thumb/1/17/RDFSerialization-formats.png/800px-RDFSerialization-formats.png page RDF 2014-09-15