451 KiB
451 KiB
| 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 | youtube | list | feed | discord | crunchbase | docs | devtools | app | telegram | forum | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | Standards | ETSI | https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0213.html | A Guide To Writing World Class Standards | - A world class standard should have well-defined objectives that respond to real needs in a timely manner.<br>- Its technical content should be complete and accurate.<br>- It should be easy to understand (or as easy as the subject matter allows!) and easy to implement.<br>- Its requirements should be expressed clearly and unambiguously.<br>- It should be validated.<br>- It should be well-maintained. | https://www.etsi.org/images/files/Brochures/AGuideToWritingWorldClassStandards.pdf | Paper | Standardization | 2020-07-29 | |||||||||||||||||||||||||||||||
| 3 | Standards | Medium | Tim Bouma | Trust Frameworks? Standards Matter | He points at the NIST documents about it [Developing Trust Frameworks to Support Identity Federations](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8149.pdf) published in 2018. He also points at the Canadian government’s definition of standards.<br>a document that provides a set of agreed-upon rules, guidelines or characteristics for activities or their results. Standards establish accepted practices, technical requirements, and terminologies for diverse fields.” He goes on to highlight a lot of the work being done in Canada and where it all sits relative to being a standard - “In closing, there are lots of trust frameworks being developed today. But to be truly trusted, a trust framework needs to either apply existing standards or become a standard itself.” | Note: This post is the author’s opinion only and does not represent the opinion of the author’s employer, or any organizations with which the author is involved. Over the past few years, and… | https://medium.com/@trbouma/trust-frameworks-standards-matter-47c946992f44 | Post | Standardization | 2020-11-26 | ||||||||||||||||||||||||||||||
| 4 | Standards | WeAreOpen | Doug Belshaw | Open standards should be developed openly | Open standards should be developed openly because not enough people work to ensure that equity is central to innovation and development. We believe that openness is an attitude, and one which bears fruit over time from which everyone can benefit.<br>5 | Imagine a community garden with abundant fruit and vegetables for anyone to come and pick and consume. Now imagine a factory creating standardised parts to be used by manufacturers. The two metaphors… | https://blog.weareopen.coop/open-standards-should-be-developed-openly-1f0cf552308d | Post | Standardization | 2021-08-19 | ||||||||||||||||||||||||||||||
| 5 | Standards | ContinuumLoop | Darrell O'Donnell | Premature Standardization & Interoperability | Here’s my premise – we don’t have standards nor interoperability – at least not as people really need. We have been through a process that is powerful and good – but what we have is what I call “premature standardization.” It’s a great start but nowhere near where things will be. | Within the decentralized identity space its premature to think we have real Standardization & Interoperability | https://www.continuumloop.com/premature-standardization-interoperability/ | Post | Standardization | 2022-09-11 | ||||||||||||||||||||||||||||||
| 6 | Standards | Trinsic | Anna Johnson | Trinsic Basics: What Are SSI Standards? | There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards. | Our engineering team ensures that the Trinsic platform is always based on the most recent SSI standards and protocols. | https://trinsic.id/what-are-ssi-standards/ | page | Standardization | 2020-11-12 | ||||||||||||||||||||||||||||||
| 7 | Standards | Scripting.com | Dave Winer | Manifesto: Rules for standards-makers | I've used all kinds of formats and protocols in a long career as a software developer, even created a few. My new manifesto summarizes what I've learned about what works and what doesn't. | http://scripting.com/2017/05/09/rulesForStandardsmakers.html | Post | Standardization | 2017-05-08 | |||||||||||||||||||||||||||||||
| 8 | Standards | ContinuumLoop | Darrell O'Donnell | Why Engage with Standards? | too many people complain about problems but don’t step to Fix It!. There are certainly a lot of flawed standards – but they make interoperability possible – not perfect – but possible. If you haven’t used them then you have no right to complain that they are too complex, too simple (even in the same standard) or too domain specific – or any of the other rants and raves that go on. <br><br>If you’re willing to put up with a lot of work for incremental improvements then step up and join a standard. Whether that is a (relatively) fast moving standard group like OASIS (www.oasis-open.org) or a slower but more international group like ISO you will learn. You’ll also benefit from working with experts. These experts donate their time and are more than happy to provide ideas, guidance, and leadership. | https://www.continuumloop.com/why-engage-with-standards/ | Post | Standardization | 2013-09-28 | |||||||||||||||||||||||||||||||
| 9 | Standards | Forgerock | Who Are the Identerati? - ForgeRock | You’re familiar with digital identity standards like OpenID Connect, OAuth, and User-Managed Access, fundamental elements of privacy and security on the internet. But have you ever wondered how they came to be? A lot of work on these protocols went on (and goes on) behind the scenes at the Internet Identity Workshop (IIW), a bi-annual gathering of identity experts where we work on improving the identity systems that make the web run. It’s a great event that’s flown under the radar, so I’m excited to share a new documentary on IIW, “Not Just Who They Say We Are: Claiming our identity on the Internet”. This short film shines a light on the stealth community of “Identerati” at IIW that are defining and refining digital identity. | You’re familiar with digital identity standards like OpenID Connect, OAuth, and User-Managed Access, fundamental elements of privacy and security on the internet. But have you ever wondered how they came to be? A lot of work on these protocols went on (and goes on) behind the scenes at the Internet Identity Workshop (IIW), a bi-annual gathering of identity experts where we work on improving the identity systems that make the web run. | https://www.forgerock.com/blog/who-are-the-identerati | Post | Standardization | 2017-03-22 | |||||||||||||||||||||||||||||||
| 10 | Standards | Wikipedia | Who Runs the Internet? | NO ONE PERSON, COMPANY, ORGANIZATION OR GOVERNMENT RUNS THE INTERNET.<br>The Internet itself is a globally distributed computer network comprised of many volantarily interconnected autonomous networks. Similarly, its overnance is conducte by a decentralized and international multi-stakeholder network of interconnected autonomous groups drawing from civil society, the private sector, governments, the academic and research communities, and national and international organizations. They work cooperatively from their respective roles to create shared policies and standards that mantian the Internet's global interoperability for the public good. | https://es.wikipedia.org/wiki/Archivo:Who-Runs-the-Internet-graphic.png | https://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Who-Runs-the-Internet-graphic.png/1024px-Who-Runs-the-Internet-graphic.png | wiki entry | Standardization | 2013-01-31 | |||||||||||||||||||||||||||||||
| 11 | Standards | Hyperledger | Identity Standards | We hope to accumulate links here that talk to all Identity Standards work. Short updates form this will be used in the paper. Some are already input into the paper and need work polishing up. | https://wiki.hyperledger.org/display/IWG/Identity+Standards | wiki entry | Decentralized Identity Stack | Hyperledger Identity Working Group | 2019-05-20 | |||||||||||||||||||||||||||||||
| 12 | Standards | CCG Mailing List | Manu Sporny | Roadmap: Verifiable Trust Standards | Green - General data format standards<br>Yellow - Vocabulary standards (I the mislabeled VC work)<br>Magenta - Protocol standards (I mislabeled DID Resolution)<br>Red - Low-level cryptographic primitives<br>Purple - General crypto packaging/protocol standards<br>Orange - Application layer standards | https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0014.html | https://lists.w3.org/Archives/Public/public-credentials/2021Mar/att-0014/VerifiableTrustStandards.png | Discussion | Decentralized Identity Stack | Credentials Community Group | 2021-03-03 | |||||||||||||||||||||||||||||
| 13 | Standards | CCG Mailing List | https://lists.w3.org/Archives/Public/public-credentials/2021Feb/att-0134/2021-Linked-Data-Security.pdf | Manu Sporny | Linked Data Security | The attached slide deck provides a basic overview (with examples) of Linked Data Security as well as the specifications in that orbit. The W3C CCG is actively developing a number of these specifications. | https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0134.html | Discussion | Decentralized Identity Stack | Credentials Community Group | 2021-02-29 | |||||||||||||||||||||||||||||
| 14 | Standards | arxiv | A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems (NIST CYBERSECURITY WHITE PAPER) | Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing both within organizations as well as on the Internet more broadly. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues such as encouraging mass data collection and user tracking. Blockchain technology has the potential to support novel data ownership and governance models with built-in control and consent mechanisms, which may benefit both users and businesses by alleviating these concerns; as a result, blockchain-based IDMSs are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in architecture, governance models, and other salient features. We provide context for the taxonomy by describing related terms, emerging standards, and use cases, while highlighting relevant security and privacy considerations. JULY 9, 2019 | https://arxiv.org/pdf/1908.00929.pdf | Paper | DRAFT | Decentralized Identity Stack | 2020-01-14 | |||||||||||||||||||||||||||||||
| 15 | Standards | Personal | Tim Bouma | Building Blocks for a New Architecture | First, you will see the Issuer, Holder and Verifier. This is the archetypal pattern of the decentralized architecture. An issuer issues something to a holder, who then presents it to a verifier, who make a decision. A simple example: government(issuer) issues you a passport (holder), which you present to a border control officer (verifier) who lets you through the gate. When you look at all the use cases (described above), they all fall into this pattern. https://i.imgur.com/qGXEnW1.png | Note: These are my opinions only, and not that of my employer. All information used in developing this post is open and freely available. No statements should be considered as advice or representing… | https://medium.com/@trbouma/building-blocks-for-a-new-architecture-fda2238ac005 | Post | Decentralized Identity Stack | 2019-09-23 | ||||||||||||||||||||||||||||||
| 16 | Standards | DIF | Oliver Terbu | The Self-Sovereign Identity Stack | <table><tr><td>Layer</td><td>Examples</td></tr><tr><td>Application</td><td>Selective Disclosure, music app, rideshare service, extensions, etc.</td></tr><tr><td>Implementation</td><td>DIF Hubs, Indy Agents, uPort app, etc.</td></tr><tr><td>Payload</td><td>JSON-LD, JWT, CWT</td></tr><tr><td>Encoding</td><td>ProtoBuf, Cap'n Proto, MessagePack, JSON, CBOR, etc.</td></tr><tr><td>Encryption</td><td>Ciphersuite, JWE, etc.</td></tr><tr><td>DID AuthN</td><td>Key ownership, verification, challenge/response, etc.</td></tr><tr><td>Transport</td><td>QR Code, HTTP, BLE, NFC, FTP, SMTP, etc.</td></tr><tr><td>DID Resolution</td><td>DID-DID Doc / service and key resolution</td></tr><tr><td>DID Operations</td><td>CRUD support for a DID Doc</td></tr><tr><td>Storage</td><td>Optional, separate storage of DID metadata</td></tr><tr><td>Anchor</td><td>Bitcoin, Ethereum, Veres One, Sovrin, etc.</td></tr></table> | For anyone who isn’t working on the emerging technologies and concepts being developed in the self-sovereign identity (SSI) community, it can be difficult to track and digest all the concepts, tools… | https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45 | https://miro.medium.com/v2/resize:fit:1200/1*4zUczSBaVH-8qilvK4nKwQ.png | Post | Decentralized Identity Stack | 2019-01-27 | |||||||||||||||||||||||||||||
| 17 | Standards | DIF | https://gist.github.com/creatornader/c8a20c534d3cf8f65a9b34ce2ad81725 | Nader Helmy | Overview of Decentralized Identity Standards | we can think of each specification as addressing one or more of the SSI “building blocks” that we described above. In some cases a standard may be a bridge between layers, enabling a closer link between connections, data, and keys, making the ecosystem more secure as a whole. What you will find below is a list of all relevant standards, links to every specification, the organizations they belong to, their relationship to the ecosystem, and their relative maturity as internet technologies. | There are a number of organizations working towards standardization of technologies that span across the web. Of these, there are a handful of umbrella organizations that are particularly important… | https://medium.com/decentralized-identity/overview-of-decentralized-identity-standards-f82efd9ab6c7 | https://miro.medium.com/v2/resize:fit:1000/1*oDeFSKBXhWkltGqXZ82yDA.png | Post | Decentralized Identity Stack | 2020-03-02 | ||||||||||||||||||||||||||||
| 18 | Standards | SSIMeetup.org | https://www.youtube.com/watch?v=RllH91rcFdE | Drummond Reed | Evernym | The Story of Open SSI Standards | Drummond Reed, Chief Trust Officer at Evernym and Sovrin Foundation Trustee, features in our first Webinar “The Story of SSI Open Standards” by giving us the background on the foundation of Self Sovereign Identity. Drummond explains the technical and development aspects of DIDs, DKMS, DID Auth and Verifiable Credentials that will make Self Sovereign Identity possible. | https://ssimeetup.org/story-open-ssi-standards-drummond-reed-evernym-webinar-1/ | https://imgur.com/6MLNgXal.png | Presentation | Decentralized Identity Stack | 2018-04-27 | ||||||||||||||||||||||||||||
| 19 | Standards | DIF | SSI Architectural Stack and Community Efforts Overview | While a more thorough (and competitive) separation of concerns might slice today’s and tomorrow’s identity systems into more modular and interchangeable parts at many more layers, the diagram used here organizes the space into just three broad divisions, which map roughly to the bottom three in the mapping dominant in the Aries & ToIP communities. For a more detailed and complex mapping, see the forthcoming map by the DIF interoperability working group. | https://github.com/decentralized-identity/interoperability/blob/master/assets/ssi-architectural-stack--and--community-efforts-overview.pdf | infographic | Decentralized Identity Stack | 2020-09-23 | ||||||||||||||||||||||||||||||||
| 20 | Verifiable Credentials,Standards | Personal | Kristina Yasuda | VC spec map | Distributed ID Learning Path | There is a lot of information about decentralized IDs on the web. I struggled too. (I still do that lol)<br><br>There are many standards for decentralized identities, and they are interdependent and interrelated, as you can see from the diagram below. | Describes pre-requisite knowledge, including JSON, JSON-LD, JWT, JWS, JWK, JWA, and sometimes CBOR. She then goes on to break down knowledge areas beginning with the basics: DID-Core, DID-Resolution, DID-Spec, DID Use-Cases. Next, she covers Verifiable Credentials with VC-Data Model, VC Use-Cases, and VC-Implementors Guide, and also Transport, Credential Presentation, and Other Data Formats. | https://translate.google.com/translate?sl=auto&tl=en&u=https://kristinayasuda.com/posts/decentralized-identity-catch-up-path/ | https://images.ctfassets.net/iifz0jg6o9rt/1frepoi3bOWvEZOIAKlWkC/de5013e3d77fc29ce3c19a3a532c603d/IBO_WebUI.JPG | Post | Interoperability, Decentralized Identity Stack | 2020-12-09 | ||||||||||||||||||||||||||||
| 21 | Standards | WebOfTrustInfo | RWoT | Recommendations for Decentralized Key Management Systems | A decentralized key management system (DKMS) aims to solve how consumers can manage their own keys and certificates without relying on a third-party provider having access or controls over the keys.. This method helps to ensure that no third-party can compromise the integrity and security of the system as a whole. Entities can use the system to safely authenticate each other and validate keys and certificates. Centralized key management systems (CKMS) manage key and certificate creation, signing, and validity. Specific problems arise when these authorities become unavailable, or the data they control becomes corrupted or known. Central authorities often become choice targets for attackers. This document proposes to meet these requirements with a decentralized blockchain ledger for providing an oracle of trust and leave control over all keys with end users. The use of a blockchain permits globally readable identifiers and public data to be shared in a secure manner that is not vulnerable to the man-in-the-middle attack or system wide compromise and permits consumers to be self-sovereign. This leaves consumers with the task of key management and protection. This document covers various ideas for how users may create, recover, backup, and revoke keys and provides recommended suggestions. | https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/dkms-recommendations.md | Paper | Decentralized Identity Stack | 2017-09-15 | |||||||||||||||||||||||||||||||
| 22 | Standards | SSIMeetup.org | https://www.slideshare.net/SSIMeetup/decentralized-key-management-dkms-an-essential-missing-piece-of-the-ssi-puzzle-drummond-reed | Drummond Reed | DKMS - An Essential Missing Piece of the SSI Puzzle | DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (CAs). With DKMS, the initial “root of trust” for all participants is any blockchain or distributed ledger that supports DIDs. This webinar will explain why we need DKMS, what a DKMS-compatible identity wallet looks like, how DKMS can solve some longstanding problems in wallet backup and recovery, and where DKMS is headed for standardization. | If you can't manage the keys for your DIDs (Decentralized Identifiers), then the SSI engine will never get started. That's why DKMS (Decentralized Key Management System) is one of the core open standards in the DID "stack". | http://ssimeetup.org/decentralized-key-management-dkms-essential-missing-piece-ssi-puzzle-drummond-reed-webinar-8/ | https://i.imgur.com/5qc1qrG.png | Presentation | Decentralized Identity Stack | 2018-06-28 | ||||||||||||||||||||||||||||
| 23 | Verifiable Credentials | Wikipedia | Verifiable Credentials - Wikipedia | Verifiable credentials (VCs) are the electronic equivalent of the physical credentials that we all possess today, such as: plastic cards, passports, driving licences, qualifications and awards, etc. The data model for verifiable credentials is a World Wide Web Consortium Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web" published 19 November 2019. | https://en.wikipedia.org/wiki/Verifiable_credentials | https://upload.wikimedia.org/wikipedia/commons/thumb/5/51/VC_triangle_of_Trust.svg/1200px-VC_triangle_of_Trust.svg.png | wiki entry | About | 2023-04-25 | |||||||||||||||||||||||||||||||
| 24 | Verifiable Credentials | Auth0 | Vittorio Bertocci, Filip Skokan | Identity, Unlocked... Explained: Season 2, Ep. 2 | a conversation about a few three-letter extensions to OAuth (which, incidentally, would also fit well in a pirate incantation!): PAR, RAR, and JAR. Filip is a Senior Engineer II at Auth0, the author of a popular book on open source identification, and a contributor to both the [IETF](https://www.ietf.org/) and the [OpenID Foundation](https://openid.net/foundation/).<br>$5 | PAR, RAR, and JAR with Filip Skokan | https://auth0.com/blog/identity-unlocked-explained-season-2-ep-2/ | Post | About | 2021-03-12 | ||||||||||||||||||||||||||||||
| 25 | Verifiable Credentials | Digital Bazaar | https://docs.google.com/presentation/d/1GMQy4rI093c_9zojwLRgp2r-fTscpDUSfX-wqwBk4j4/edit#slide=id.g3605fe1474_2_0 | Manu Sporny | IIW26, IIW | IIW26 Primer On DIDs and VCs | A new type of globally resolvable, cryptographically-verifiable identifier, registered directly on a distributed ledger (aka Blockchain). Portable identifiers for any person, organization, or thing that does not depend on a centralized authority, are protected by cryptography, and enable privacy and data portability. | https://docs.google.com/presentation/d/1GMQy4rI093c_9zojwLRgp2r-fTscpDUSfX-wqwBk4j4/edit#slide=id.g3605fe1474_2_0 | https://i.imgur.com/TeMxwwW.png | Presentation | About | 2018-03-05 | ||||||||||||||||||||||||||||
| 26 | Verifiable Credentials | Evernym | Daniel Hardman | A Gentle Introduction to Verifiable Credentials | But while digital records are nothing new, today’s credentials come with certain ‘cryptographic superpowers’ that make them tamperproof, secure, and verifiable. Whereas a simple digital copy of a car title can easily be edited, a verifiable digital credential is one that has been issued by a trusted authority for, and only for, its holder. | What are verifiable credentials, and what requirements must they meet to conform to W3C specifications? Let's dig in. | https://www.evernym.com/blog/gentle-introduction-verifiable-credentials/ | Post | About | 2019-10-24 | ||||||||||||||||||||||||||||||
| 27 | Verifiable Credentials | WebOfTrustInfo | RWoT | A Verifiable Credentials Primer | NOTE: "Verifiable Claims" are now known as "Verifiable Credentials". The W3C Verifiable Claims Working Group's experience with using the term "Verifiable Claims" demonstrated that it led to confusion in the marketplace. The group has since found consensus in shifting to use the term "Verifiable Credentials", which contain "Claims". | https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/topics-and-advance-readings/verifiable-credentials-primer.md | Paper | About | 2018-07-17 | |||||||||||||||||||||||||||||||
| 28 | Verifiable Credentials | SSIMeetup | Tyler Ruff | Verifiable Credentials 101 for SSI | Tyler Ruff, product manager at Evernym, will be our next guest to walk us through Verifiable Credentials in the context of Self-Sovereign Identity. He will cover how they are created, issued and shared, as well as cover some common technical questions. | Tyler Ruff, product manager at Evernym, will be our next guest to walk us through Verifiable Credentials in the context of Self-Sovereign Identity. He will cover how they are created, issued and shared, as well as cover some common technical questions. | http://ssimeetup.org/verifiable-credentials-101-ssi-tyler-ruff-webinar-11/ | Presentation | About | 2018-09-12 | ||||||||||||||||||||||||||||||
| 29 | Verifiable Credentials | Hackernoon | Verifiable Credentials: What They Are, Why They Matter | From permanent resident cards to anonymous payments to automatic notarization, verifiable credentials and DIDs are a technology whose time has arrived. Use cases are currently being piloted; many will surface in coming months and years. Security on the internet as we know it may be broken, but it is not beyond saving. A touch of the cryptographic wand, and we'll be able to repair trust once more. | https://hackernoon.com/verifiable-credentials-what-they-are-why-they-matter-kl133t3d | Post | About | 2020-10-02 | ||||||||||||||||||||||||||||||||
| 30 | Verifiable Credentials | Arcblock | Understand Verifiable Cresidentials in 10 Minutes | This article is a soft introduction into Verifiable Credentials and the potential use cases for organizations, businesses and government institutions and creating new levels of trust for individuals and the services/institutions they use. | Born for blockchain 3.0 | https://www.arcblock.io/en/post/2020/04/15/verifiable-credentials | Post | About | 2020-04-15 | |||||||||||||||||||||||||||||||
| 31 | Verifiable Credentials | Affinidi | What are Verifiable Credentials | At the most basic level, verifiable credentials, or VC in short, are tamper-proof credentials that can be verified cryptographically. | How W3C Verifiable Credentials (VC) Work: Part 1 – Issuance | https://academy.affinidi.com/what-are-verifiable-credentials-79f1846a7b9 | page | About | 2022-11-17 | |||||||||||||||||||||||||||||||
| 32 | Verifiable Credentials | Personal | Michael Ruminer | The Role of Witness Organizations in Verifiable Credentials | The basis is that not every source of a verifiable credential has an interest in issuing verifiable credentials and that it is not only logical but beneficial to the ecosystem of trust that witness organizations will issue on behalf of these sources. | Verifiable credentials aren’t just P2P.. “On the Role of Witness Organizations in Verifiable Credentials” is published by Michael Ruminer. | https://medium.com/@m.ruminer/on-the-role-of-witness-organizations-in-self-sovereign-identity-or-vcs-aren-t-just-p2p-e2cbafce6928 | https://miro.medium.com/v2/resize:fit:915/1*yKIkcfnadFv8uPblIsMk9g.png | Post | About | 2021-03-09 | |||||||||||||||||||||||||||||
| 33 | Verifiable Credentials | HackerNoon | An introductory dive into VCs (verifiable credentials) | Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. They are issued and cryptographically signed documents, intended to be understood by computers rather than people. | https://hackernoon.com/understanding-the-verifiable-credentials-vcs-it1535e9 | Post | About | 2021-04-28 | ||||||||||||||||||||||||||||||||
| 34 | Verifiable Credentials | Evernym | Brent Zundel | How Does a Verifier Know the Credential is Yours? | A link secret is a large random number, wrapped in a way that allows the holder to prove that they know the secret. | This post examine how link secrets bind a credential to its holder and enable powerful compound proofs without the risk of correlation. | https://www.evernym.com/blog/how-does-a-verifier-know-the-credential-is-yours/ | https://www.evernym.com/wp-content/uploads/2021/08/linksecrets-social.png | Post | About | 2021-08-10 | |||||||||||||||||||||||||||||
| 35 | Verifiable Credentials | Ubisecure | Petteri Stenius | Introduction to Verifiable Credentials | The Verifiable Credentials specification is quite new, and many pieces that are required to create interoperable solutions are still incomplete or missing at time of writing. However, there is significant momentum around verifiable credentials (VCs). This is partly attributed to VCs being part of the solution for blockchain-based decentralised identity. | An introduction to the Verifiable Credentials concept, including the wallet analogy and privacy considerations - SSI and ZKP. | https://www.ubisecure.com/identity-management/verifiable-credentials/ | page | About | 2021-08-04 | ||||||||||||||||||||||||||||||
| 36 | Verifiable Credentials | Affinidi | 8 Reasons to use Verifiable Credentials | VCs are interoperable across many systems and can be used in almost every possible scenario. | The growing digitalization of our lives means that we interact with thousands of apps, hundreds of companies, and possibly millions of users each year, depending on what we do online. While these… | https://academy.affinidi.com/8-reasons-to-use-verifiable-credentials-300833276b52 | https://miro.medium.com/v2/resize:fit:1200/1*GlQVpv3oPkfNU2eNa9JdTQ.png | page | About | 2021-09-08 | ||||||||||||||||||||||||||||||
| 37 | Verifiable Credentials | HelpNetSecurity | Verifiable credentials are key to the future of online privacy | - All the data is decentralized, meaning there’s no need for a database of student records that could be jeopardized. Alice’s data lives with her.<br>- The employer doesn’t need to keep a copy of Alice’s transcript to verify her education.<br>- The college doesn’t play intermediary and doesn’t have access to the list of organizations Alice shares her data with. Other parties have no way of correlating this data as each exchange is private and unique.<br>- If desired, Alice could pick and choose what she wants to share. She could prove her degree without sharing her date of graduation or GPA, for example. | Verifiable credentials are the digital equivalents of the paper documents we carry in our wallets and prove who we are in the physical world. | https://www.helpnetsecurity.com/2021/07/26/verifiable-credentials/ | Post | About | 2021-07-26 | |||||||||||||||||||||||||||||||
| 38 | Verifiable Credentials | IDCommons | Stew Whitman, Alka Lachhwani | IIW | Self Attested vs Chain of Custody - assurance levels in data provenance in VCs | There are two important factors in establishing “truth” or the trustworthiness of the information. Attributional and Reputational. You need to have both to have trust.<br><br>Digital needs higher level of attestation because it is easier to forge and easier to propagate that forgery. | https://iiw.idcommons.net/23G/_Self_Attested_vs_Chain_of_Custody_-_assurance_levels_in_data_provenance_in_VCs | Session Notes | About | 2021-05-06 | ||||||||||||||||||||||||||||||
| 39 | Verifiable Credentials | BLOCK6 | Pranav Kirtani | How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding | Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding. | Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the… | https://pranavkirtani.medium.com/how-a-combination-of-federated-identity-and-verifiable-credentials-can-help-with-customer-7e6518feb018 | https://miro.medium.com/v2/resize:fit:1200/0*ENXUBvSdImT5qL_f | Post | About | 2022-07-27 | |||||||||||||||||||||||||||||
| 40 | Verifiable Credentials | Affinidi | Open Badges | Compare and Contrast: OpenBadges vs Verifiable Credentials | As we move towards a world of digital identity, many ways of sharing and verifying Personally Identifiable Information are emerging. Two such modes that we’ll talk about today are Open Badges and Verifiable Credentials. | Open Badges are a format for issuing digital badges while verifiable credentials are tamper-proof credentials for implementing self sovereign identity. | https://academy.affinidi.com/compare-and-contrast-openbadges-vs-verifiable-credentials-d504c054d5db | https://miro.medium.com/v2/resize:fit:1200/1*GfdafX7dlTbrOg57MvfIMA.png | page | Comparisons | 2022-11-17 | |||||||||||||||||||||||||||||
| 41 | Verifiable Credentials | Affinidi | Non-Fungible Tokens (NFTs) vs Verifiable Credentials (VCs) | A common thread that connects both NFTs and VCs is that they leverage the potential benefits of the digital world to give users more security, flexibility, and freedom to monetize. | Are Non-fungible tokens (NFTs) and Verifiable Credentials synonymous? Well, NFTs verify the ownership of an object while VCs uniquely identify an entity. | https://academy.affinidi.com/non-fungible-tokens-nfts-vs-verifiable-credentials-vcs-cd0ebb13f1fb | https://miro.medium.com/v2/resize:fit:1200/1*SQxFteogQX5jwf-yC_y8eA.jpeg | page | Comparisons | 2022-11-17 | ||||||||||||||||||||||||||||||
| 42 | Verifiable Credentials | CCG Mailing List | Michael Herman | ERC-721 Non-Fungible Token Standard on Ethereum vs. VCs on Hyperledger Indy | When are Hyperledger Indy/Sovrin VCs better than Ethereum smart contracts for NFEs/NFTs (non-fungible entities/tokens)?<br><br>It seems obvious but I don't have a detailed/worked out answer. One project I'm associated with wants to use the [ERC-721 Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) on Ethereum but I believe VCs are a better route to take. Part of the desire to stay on Ethereum is there is quite a vibrant NFT community on Ethereum and lots of different EC-721 tokens. | https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0059.html | Discussion | Comparisons | Credentials Community Group | 2021-02-11 | ||||||||||||||||||||||||||||||
| 43 | Verifiable Credentials | Affinidi | Compare and Contrast — IRMA vs Verifiable Credentials | IRMA [is] based on the Idemix technology. Idemix is a public-private key pair where the private key is used by the issuer to sign a credential and the public key is used by the verifier to establish that the credential is signed by the issuer and hence is authentic. [...] Verifiable credentials, or VC in short, are tamper-evident credentials that can be verified cryptographically. | Do you need a distributed ledger technology for implementing SSI? IRMA vs VCs can show different ways to implement self sovereign identity. | https://academy.affinidi.com/compare-and-contrast-irma-vs-verifiable-credentials-58e4b30d85f1 | page | Comparisons | 2022-11-17 | |||||||||||||||||||||||||||||||
| 44 | Verifiable Credentials | IDCommons | Grace Rachmany | IIW | Could an NFT be a VC? | Case discussed: A group of villages in Africa using a cryptocurrency platform for alternative currencies. Different organizations issue the coins under different circumstances. When you accept a currency, you want to know who is the issuer. The Red Cross might be more or less trusted than the local leader or agricultural cooperative as the issuer of a currency that is supposedly equivalent to a shilling.<br><br>What types of tech could be used for this?<br><br>- Multiple currencies on the blockchains<br>- Certifications in the form of some kind of NFT issued by the issuer.<br>- Limited supply tokens or NFTs that are “expired” when you use them<br>- Open Credential Publisher framework was suggested<br>- VCs are generally authorizations associated with a person, so maybe a person could have the VC and show their credit rating in some way while they are making a transaction<br>- Similarly maybe the VC belongs to the organization that is issuing the coin, proving its reputation over time. | https://iiw.idcommons.net/20I/_Could_an_NFT_be_a_VC%3F | Session Notes | Comparisons | 2021-05-06 | ||||||||||||||||||||||||||||||
| 45 | Verifiable Credentials | Personal | Timothy Ruff | How does VC Functional Stack compare to #ToIP Stack? | 1. ToIP Layers 2 & 3 compare to Functional Layer 2<br>2. ToIP Layer 4 compares to Functional Layers 3 & 4 (horizontal layer for VC Management, vertical layer for Applications)<br>3. Functional stack doesn't require #blockchain<br>4. Functional Stack doesn't detail steps for trust or verification; ToIP Stack doesn't separate management or storage<br>5. Functional Stack clarifies functions, roles, and potential business models; ToIP stack clarifies trust & security They are complementary, not contradictory. | https://twitter.com/rufftimo/status/1301314001251438593 | https://i.imgur.com/8zakrMQ.png | Thread | Comparisons | 2020-09-03 | ||||||||||||||||||||||||||||||
| 46 | Verifiable Credentials | CCG Mailing List | Michael Herman | What are VCs similar to? | The chip in your e-passport is the analogy I’ve been most successful with<br>An issuer gives it to you.<br>You carry it around and show to whom you choose<br>The verifier can check its integrity without contacting the issuer<br>“A VC is like the chip in your passport - bit for any document type”<br>So far the best analogy I’ve found. Policy makers say “ah, I see” | https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0338.html | Discussion | Comparisons | Credentials Community Group | 2021-08-23 | ||||||||||||||||||||||||||||||
| 47 | Verifiable Credentials, Object Capabilities | fossandcrafts | Hygiene for a computing pandemic | This episode of FOSS and Crafts features Christopher Lemmer Webber discussing the object capability security approach. Its a generalization not specific to VCs, continuing from the conversation on the CCG mailinglist, [Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps](https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html), we shared last month.<br> | The podcast *show-notes include an epic list of references* supporting the discussion. | https://fossandcrafts.org/episodes/20-hygiene-for-a-computing-pandemic.html | Post | Comparisons, Main | Object Capabilities | 2021-01-03 | ||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||
| 51 | Verifiable Credentials | VCWG | List of Implementations for the Verifiable Credentials Data Model | <ul><li>Go<ul><li><a href="https://github.com/TBD54566975/ssi-sdk/tree/main/credential">Credential Manifest Builders</a> (DI & JWT)</li><li><a href="https://github.com/hyperledger/aries-framework-go">Hyperledger Aries Framework Go</a> (DI & JWT)</li></ul></li><li>Java<ul><li><a href="https://github.com/danubetech/verifiable-credentials-java">Verifiable Credentials Java</a> (DI & JWT)</li></ul></li><li>JavaScript/TypeScript<ul><li><a href="https://github.com/digitalbazaar/vc-js">Verifiable Credentials JS Library</a> (DI)</li><li><a href="https://github.com/transmute-industries/verifiable-data/tree/main/packages/vc.js">Verifiable Data Credential JS Library with JWT</a> (DI & JWT)</li><li><a href="https://github.com/decentralized-identity/did-jwt-vc">W3C Verifiable Credentials and Presentations in JWT format</a> (JWT)</li></ul></li><li>Kotlin<ul><li><a href="https://github.com/microsoft/VerifiableCredential-SDK-Android">Verifiable Credentials in Kotlin</a> (JWT)</li></ul></li><li>Python<ul><li><a href="https://github.com/hyperledger/aries-cloudagent-python">Hyperledger Aries Cloud Agent - Python (ACA-Py)</a> (DI & JWT)</li></ul></li><li>Rust<ul><li><a href="https://github.com/spruceid/didkit">DIDKit</a> (DI & JWT)</li></ul></li><li>Swift<ul><li><a href="https://github.com/microsoft/VerifiableCredential-SDK-iOS">Verifiable Credentials in Swift</a> (JWT)</li></ul></li></ul> | https://github.com/w3c/verifiable-credentials/blob/main/implementations.md | Page | Implementations | 2022-06-03 | ||||||||||||||||||||||||||||||||
| 52 | 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 | |||||||||||||||||||||||||||||||
| 53 | 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 | |||||||||||||||||||||||||||||||
| 54 | 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 | |||||||||||||||||||||||||||||||
| 55 | Verifiable Credentials | Ontology | Verifiable Claim Protocol | The entire workflow of the verifiable claim is shown in the figure below. It contains three major parts:<br><br>Request claim;<br>Issue claim;<br>Verify claim. | Ontology decentralized identification protocol based on W3C DID specifications. - ontology-DID/claim_spec.md at master · ontio/ontology-DID | https://github.com/ontio/ontology-DID/blob/master/docs/en/claim_spec.md | Specification | Implementations | 2017-03-20 | |||||||||||||||||||||||||||||||
| 56 | Verifiable Credentials | Crossword | Cybersecurity NGI | Crossword wins NGI Atlantic funds for Verifiable Credentials project | European Commission’s Next Generation Internet (NGI) initiative to lead a project to test the OpenID Foundation’s protocols for transferring verifiable credentials. Crossword’s partners in this project are Spruce Inc from the USA and Fraunhofer from Germany | https://www.crosswordcybersecurity.com/post/next-generation-internet-grant-win | https://static.wixstatic.com/media/082467_48feff2ccec04cb682e6101aefebd971~mv2.jpg/v1/fill/w_1000,h_563,al_c,q_85,usm_0.66_1.00_0.01/082467_48feff2ccec04cb682e6101aefebd971~mv2.jpg | Post | Implementations | 2022-08-04 | ||||||||||||||||||||||||||||||
| 57 | Verifiable Credentials | Identity.com | Identity.com Verifiable Credential Library | This Javascript Library provides functionality around Verifiable Credentials (VC), a W3C standard. Enables Validators to issue, Credential Wallets to verify, filter and Requesters to verify credentials. | Verifiable Credential and Attestation Library. Latest version: 3.0.2, last published: 4 months ago. Start using @identity.com/credential-commons in your project by running `npm i @identity.com/credential-commons`. There are 3 other projects in the npm registry using @identity.com/credential-commons. | https://www.npmjs.com/package/@identity.com/credential-commons | code | Implementations | 2023-02-13 | |||||||||||||||||||||||||||||||
| 58 | Verifiable Credentials | Personal | Samuel Smith | VC Spec Enhancement Proposal | the VC standard appears to be an adoption vector for Linked Data, not the other way around. My overriding interest is that the concept of a VC as a securely attributable statement is a very powerful and attractive one and therefore should be widely adopted. We should therefore be picking the best technologies that best support broad VC adoption, not the other way around. | https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md | Paper | Literature | 2022-04-04 | |||||||||||||||||||||||||||||||
| 59 | Verifiable Credentials | Personal | Phil Windley | Verifiable Credential Exchange | Multi-source identity (MSI) depends on issuing, exchanging, and verifying digital credentials. The specification for verifiable credentials is being formulated by the World Wide Web Consortium’s Verifiable Credentials Working Group. Verifiable credentials provide a standard way to express credentials in a way that is cryptographically secure, privacy respecting, and automatically verifiable. | Verifiable credential exchange is the foundation of decentralized, online identity. This post describes how it works. | https://www.windley.com/archives/2018/12/verifiable_credential_exchange.shtml | https://www.windley.com/archives/2018/12/claim_issuing_and_presenting.png | Post | Literature | 2018-12-10 | |||||||||||||||||||||||||||||
| 60 | Verifiable Credentials | Service-centric Networking, Telekom Innovation Laboratories, Technische Universiät Berlin | Zoltán András Lux, Felix Beierle, Sebastian Zickau, Sebastian Göndör | Full-text Search for Verifiable Credential Metadata on Distributed Ledgers | The proposed solution is able to find credential types based on textual input from the user by using a full-text search engine and maintaining a local copy of the ledger. Thus, we do not need to rely on information about credentials coming from a very large candidate pool of third parties we would need to trust, such as the website of a company displaying its own identifier and a list of issued credentials. We have also proven the feasiblity of the concept by implementing and evaluating a prototype of the full-text credential metadata search service. | https://arxiv.org/abs/1909.02895 | Paper | Literature | 2019-09-06 | |||||||||||||||||||||||||||||||
| 61 | Verifiable Credentials | NDSS Symposium | Enabling Decentralised Identifiers and Verifiable Credentials for Constrained IoT Devices using OAuth-based Delegation | Abstract—Decentralised identifiers (DIDs) and verifiable credentials (VCs) are upcoming standards for self-sovereign privacypreserving identifiers and authorisation, respectively. This focus on privacy can help improve many services and open up new business models, but using DIDs and VCs directly on constrained IoT devices can be problematic due to the management and resource overhead. This paper presents an OAuth-based method to delegate the processing and access policy management to the Authorisation Server thus allowing also systems with constrained IoT devices to benefit from DIDs and VCs. | https://www.ndss-symposium.org/wp-content/uploads/diss2019_05_Lagutin_paper.pdf | Post | Literature | 2020-06-08 | ||||||||||||||||||||||||||||||||
| 62 | Verifiable Credentials | Service-centric Networking, Technische Universitat Berlin, Telekom Innovation Laboratories, Deutsche Telekom | Zoltán András Lux, Dirk Thatmann, Sebastian Zickau, Felix Beierle | Distributed-Ledger-based Authentication with Decentralized Identifiers and Verifiable Credentials | Authentication with username and password is becoming an inconvenient process for the user. End users typically have little control over their personal privacy, and data breaches effecting millions of users have already happened several times. We have implemented a proof of concept decentralized OpenID Connect Provider by marrying it with Self-Sovereign Identity, which gives users the freedom to choose from a very large pool of identity providers instead of just a select few corporations, thus enabling the democratization of the highly centralized digital identity landscape. Furthermore, we propose a verifiable credential powered decentralized Public Key Infrastructure using distributed ledger technologies, which creates a straightforward and verifiable way for retrieving digital certificates. | https://arxiv.org/abs/2006.04754 | Paper | Literature | 2020-06-06 | |||||||||||||||||||||||||||||||
| 63 | Verifiable Credentials | WebofTrustInfo | RWoT | Addition of Proof Request/Response to a formal Verifiable Credentials specification | The W3C Verifiable Credentials (hereafter VC) specification does not currently outline how credential data should be requested by a Verifier. This document outlines the approach taken at Workday and proposes it as an addition or companion to the VC spec.<br><br>At RWoT we wish to present our approach in order to get community feedback and consensus. Workday recently announced our credentialing platform and will shortly begin to issue credentials within our market verticals. We fully intend to support the community standards around credentialing and therefore wish to drive consensus in the community on a simple, standard approach for requesting and sharing VCs between a holder and verifier. | RWOT9 in Prague, The Czech Republic (September 2019) - rwot9-prague/verifiable-credentials-proof-request.md at master · WebOfTrustInfo/rwot9-prague | https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/verifiable-credentials-proof-request.md | Paper | Literature | 2019-08-26 | ||||||||||||||||||||||||||||||
| 64 | Verifiable Credentials | Personal | Tsuyoshi Matsuzaki | Verifiable Credentials (DID Credential Flows) : Technical Overview | In the perspective of W3C specification, verifiable credential (VC) doesn’t rely on DID specification. (i.e, The “id” property used in VC shouldn’t be necessarily a DID.) However, in its real implementations, it might be expected that verifiable credentials will resolve DIDs with consistent decentralized manners and technologies. Then, in this post, we also assume that DID is used with verifiable credentials.<br><br>In order to explain things plainly, I’ll include not only VC flows, but also other parts of flows, such as, DID flows or OpenID compliant flows. | Microsoft has launched ION hosting (beta) on Bitcoin mainnet, and new verifiable credentials service (private preview) on Azure Active Directory (Azure AD). In this post, I will summarize what is verifiable credentials and how it works. This style of identity and credentials are very much like our physical world. I hope this future credential backed… | https://tsmatz.wordpress.com/2020/06/25/what-is-verifiable-credentials/ | https://tsmatz.files.wordpress.com/2020/09/20200902_issuer_did.jpg | Post | Literature | 2020-06-25 | |||||||||||||||||||||||||||||
| 65 | Verifiable Credentials | CCG Mailing List | Kerri Lemoie | Add Your VC-EDU Use Cases | For Github users, submit your use cases as issues here: [https://github.com/w3c-ccg/vc-ed-use-cases/issues](https://github.com/w3c-ccg/vc-ed-use-cases/issues)<br><br>This template can help guide you: [https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md](https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md) | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0296.html | Discussion | Use Case | Credentials Community Group | 2021-07-30 | ||||||||||||||||||||||||||||||
| 66 | Verifiable Credentials | Personal | Kerri Lemoie | W3C Verifiable Credentials Education Task Force 2022 Planning | We’ve been hard at work writing use cases, helping education standards organizations understand and align with VCs, and we’ve been heading towards a model recommendation doc for the community. | At the W3C VC-EDU Task Force we’ve been planning meeting agendas and topics for 2022. We’ve been hard at work writing use cases, helping education standards organizations understand and align with… | https://kayaelle.medium.com/w3c-verifiable-credentials-education-task-force-2022-planning-efc9b07cc2a3 | Post | Use Case | 2022-01-18 | ||||||||||||||||||||||||||||||
| 67 | Verifiable Credentials | The Paypers | Better digital living with blockchain-backed verifiable credentials | The NHS can now provide you with a digital verifiable credential to prove your vaccination status, securely stored in the NHS app and easily accessible, generating a QR code to prove to airlines and employers that you are fit to fly or work. But this is just the first step in the development of an enabling technology that can bring benefits to many areas of modern life. | Better digital living with blockchain-backed verifiable credentials | https://thepaypers.com/expert-opinion/better-digital-living-with-blockchain-backed-verifiable-credentials--1250869 | Post | Use Case | 2021-08-06 | |||||||||||||||||||||||||||||||
| 68 | Verifiable Credentials | Velocity Network | On Climate Crisis and Self-Sovereign Verifiable Career Credentials | This rich verifiable self-sovereign career identity will be the ‘great transformer’ of the global labor market. It will change the way people navigate their careers and livelihoods, and how employers make talent decisions. | Reinventing how career records are shared across the global market. Empowering individuals, businesses and educational institutions through transformational blockchain technology – public, open, trusted and self-sovereign. Turn career achievements into digital credentials. Verified, secured and truly global. Own them, use them to access better opportunities. | https://www.velocitynetwork.foundation/on-climate-crisis-and-self-sovereign-verifiable-career-credentials/ | Post | Use Case | 2021-08-12 | |||||||||||||||||||||||||||||||
| 69 | Verifiable Credentials | Dock | The World of Anonymous Credentials | A credential is called a verifiable credential when its authenticity can be cryptographically checked by anyone because the credential contains a cryptographic signature by the issuer, and the issuer's public key is well known. | The main idea in anonymous credentials is that rather than considering the credential data as arbitrary bytes which are then signed by the issuer, anonymous credentials adds "structure" to the credential. | https://blog.dock.io/anonymous-credentials/ | Post | Use Case | 2022-01-20 | |||||||||||||||||||||||||||||||
| 70 | Verifiable Credentials | LTO Network | Sphereon | 25 Use Cases for Verifiable Credentials | Age-related Goods or Services, Verifying Educational Qualifications, Employment Endorsements, Background Checks, Protecting your Identity Papers, Validity of Visas, Health Checks, Sharing Health Data and Medical Records, COVID Tests for Safe Travel, Generating Boarding Pass, Checking Tickets, Access to Events or Restricted Spaces, Application for Credit Cards, Checking Eligibility for Rentals, Application for Utility Connections, Access to Services, Applying and Approving Loans, Selling/Buying a Property, Computing the Insurance Premiums, Submitting and Handling of Claims, Using Death Certificates, Driving Offences, Web shop onboarding and access, Loyalty Programs, B2B Trade | https://drive.google.com/file/d/1BrFjh6-TVkJ4Rfllh5fUTjh6hkYtPbR_/view | Paper | Use Case | 2021-05-11 | |||||||||||||||||||||||||||||||
| 71 | Verifiable Credentials | CCG Mailing List | Michael Herman | Verifiable Credential Notarization and Third-Party Notary Services Providers: User Scenarios | User Scenario A: Alice self-issues a blood pressure home reading (BPHR) credential to Dr. Bob's Clinic using SOVRONA's credential notarization services. SOVRONA is a third-party notary services provider/network.<br><br>User Scenario B: The Province of Sovronia issues a Sovronia Driver's License to Alice using SOVRONA's credential notarization services. SOVRONA is a third-party notary services provider/network. | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0109.html | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/att-0109/image003.jpg | user journies | Use Case | Credentials Community Group | 2021-07-15 | |||||||||||||||||||||||||||||
| 72 | Verifiable Credentials | IDCommons | Gena Morgan, Kevin Dean | IDCommons | IIW | Verifiable Credentials for Authentic Data in the Supply Chain | Using DiDs and VCs for verifiable product data in supply chains, leveraging the largest supply chain standard system in the world,<br><br>2.5 million users companies, over 6 billion product scans per day<br><br>Product data and attestations from a number of various authoritative sources<br><br>Leverage DIDs/VCs for distributed data sharing, verification | https://iiw.idcommons.net/10G/_Verifiable_Credentials_for_Authentic_Data_in_the_Supply_Chain | Session Notes | Use Case | 2021-05-06 | |||||||||||||||||||||||||||||
| 73 | Verifiable Credentials | IDCommons | Mahmoud Alkhraishi | IDCommons | IIW | Verifiable Credentials for Assets | General Framework on how to think of VCs for Assets including leveraging GS1 and other vocabularies in the traceability vocab.<br><br>Requirements and Opportunities that block adoption of VCs in Supply chains | https://iiw.idcommons.net/21E/_Verifiable_Credentials_for_Assets_30_min | Session Notes | Use Case | 2021-05-07 | |||||||||||||||||||||||||||||
| 74 | VCs Development | W3C | Verifiable Credentials Working Group | https://www.w3.org/2020/01/vc-wg-charter.html | Verifiable Credentials Working Group | The mission of the Verifiable Credentials (formerly known as Verifiable Claims) Working Group (VCWG) is to make expressing and exchanging credentials that have been verified by a third party easier and more secure on the Web.<br><br>The Chairs of the Working Group are Kristina Yasuda and Brent Zundel. The W3C Staff Contact for the Working Group is Ivan Herman. | https://www.w3.org/2017/vc/WG/ | Working Group | Verifiable Credentials Working Group | 2017-04-14 | https://github.com/w3c/verifiable-claims | https://lists.w3.org/Archives/Public/public-vc-wg/ | https://lists.w3.org/Archives/Public/public-vc-wg/ | |||||||||||||||||||||||||||
| 75 | VCs Development | VCWG | Manu Sporny | Verifiable Credentials Data Model v1.1 is an official W3C standard! | It's official, the Verifiable Credentials Data Model v1.1 is a W3C standard!<br><br> Verifiable Credentials Data Model v1.1<br> https://www.w3.org/TR/2022/REC-vc-data-model-20220303/<br><br>This was largely a maintenance release of the specification. The list of (minor) revisions since the v1.0 release can be found here:https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#revision-history | https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0005.html | Specificationification | Verifiable Credentials Working Group | Credentials Community Group | 2022-03-03 | ||||||||||||||||||||||||||||||
| 76 | VCs Development | VCWG | Verifiable Credentials Data Model v1.1 | Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. | Driver's licenses are used to claim that we are capable of operating a motor vehicle, university degrees can be used to claim our education status, and government-issued passports enable holders to travel between countries. This specification provides a standard way to express these sorts of claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable. | https://www.w3.org/TR/2022/REC-vc-data-model-20220303/ | https://www.w3.org/TR/2022/REC-vc-data-model-20220303/diagrams/ecosystem.svg | Specificationification | RECOMMEND | Verifiable Credentials Working Group | Verifiable Credentials Working Group | 2022-03-03 | ||||||||||||||||||||||||||||
| 77 | VCs Development | VCWG | Verifiable Credentials Data Model v2.0 | - The components that constitute a [verifiable credential](https://www.w3.org/TR/2022/WD-vc-data-model-2.0-20220811/%23dfn-verifiable-credentials) | Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. | https://www.w3.org/TR/vc-data-model-2.0/ | https://www.w3.org/TR/vc-data-model-2.0/diagrams/zkp-cred-pres.svg | Specificationification | DRAFT | Verifiable Credentials Working Group | Verifiable Credentials Working Group | 2023-05-20 | ||||||||||||||||||||||||||||
| 78 | VCs Development | VCWG | Verifiable Credential Data Integrity 1.0 | 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. | https://www.w3.org/TR/vc-data-integrity/ | https://www.w3.org/TR/vc-data-integrity/diagrams/hiw-verification.svg | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-05-15 | ||||||||||||||||||||||||||||
| 79 | VCs Development | VCWG | Verifiable Credentials Status List v2021 | This specification describes a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials. | https://www.w3.org/TR/vc-status-list/ | https://www.w3.org/TR/vc-status-list/diagrams/StatusList2021.svg | Specification | Working Draft | Verifiable Credentials Working Group | Verifiable Credentials WG | 2023-04-27 | |||||||||||||||||||||||||||||
| 80 | VCs Development | VCWG | Verifiable Credentials Implementation Guidelines 1.0 | This guide provides some examples and resources for implementing protocols which make use of verifiable credentials, beyond those available in the core specification. | https://w3c.github.io/vc-imp-guide/ | https://w3c.github.io/vc-imp-guide/diagrams/subject-ne-holder.svg | Guidance | Note | Verifiable Credentials Working Group | Verifiable Credentials Working Group | 2023-02-03 | https://github.com/w3c/vc-imp-guide | ||||||||||||||||||||||||||||
| 81 | VCs Development | VCWG | W3C Verifiable Credentials WG Test Suite | Any conforming implementation MUST pass all tests in the test suite. There are multiple test suites, each of which is detailed below. You can review the current draft implementation report. | https://w3c.github.io/vc-test-suite/ | Code | Verifiable Credentials Working Group | Verifiable Credentials Working Group | 2021-10-31 | https://github.com/w3c/vc-test-suite/ | ||||||||||||||||||||||||||||||
| 82 | VCs Development | VCWG | Verifiable Credentials Use Cases | This document does NOT attempt to define an architecture for the support of Verifiable Claims. Instead it expresses the sorts of needs that real users have that could be addressed through support for some sort of self-sovereign claim environment. It attempts to use terminology that is consistent with the other deliverables of the Verifiable Claims Working Group (you can see the relevant terms in Appendix A).<br><br>The use cases outlined here are provided in order to make progress toward possible future standardization and interoperability of both low- and high-stakes claims with the goals of storing, transmitting, and receiving digitally verifiable proof of attributes such as qualifications and achievements. The use cases in this document focus on concrete scenarios that the technology defined by the group should address. | A verifiable claim is a qualification, achievement, quality, or piece of information about an entity's background such as a name, government ID, payment provider, home address, or university degree. Such a claim describes a quality or qualities, property or properties of an entity which establish its existence and uniqueness. The use cases outlined here are provided in order to make progress toward possible future standardization and interoperability of both low- and high-stakes claims with the goals of storing, transmitting, and receiving digitally verifiable proof of attributes such as qualifications and achievements. The use cases in this document focus on concrete scenarios that the technology defined by the group should address. | https://www.w3.org/TR/vc-use-cases/ | https://i.imgur.com/J2IgVgl.png | Specification | Note | Verifiable Credentials Working Group | Verifiable Credentials Working Group | 2019-09-24 | https://github.com/w3c/vc-use-cases | |||||||||||||||||||||||||||
| 83 | VCs Development | VCWG | Verifiable Credentials Data Model Implementation Report 1.0 | The purpose of this document is to demonstrate that there are at least two interoperable implementations of processors that are capable of generating output that is conformant to the Verifiable Credentials Data Model. | https://w3c.github.io/vc-test-suite/implementations/ | Report | Verifiable Credentials Working Group | 2021-10-30 | ||||||||||||||||||||||||||||||||
| 84 | VCs Development | VCWG | The Verifiable Credential Specifications Directory | This document serves as an unofficial directory for all known Verifiable Credential specifications whether they are released by a global standards setting organization, a community group, an open source project, or an individual. | https://w3c.github.io/vc-specs-dir/ | registry | Verifiable Credentials Working Group | Verifiable Credentials WG | 2023-04-08 | https://github.com/w3c/vc-specs-dir/tree/main/specifications | ||||||||||||||||||||||||||||||
| 85 | VCs Development | VCWG | ECDSA Cryptosuite v2019 | This specification describes a Data Integrity Cryptosuite for use when generating a digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA) based on the Standards for Efficient Cryptography over prime fields using a verifiably random Elliptic Curve (secpr1). | https://www.w3.org/TR/vc-di-ecdsa/ | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-05-18 | |||||||||||||||||||||||||||||
| 86 | VCs Development | VCWG | EdDSA Cryptosuite v2022 | This specification describes a Data Integrity cryptographic suite for use when creating or verifying a digital signature using the twisted Edwards Curve Digital Signature Algorithm (EdDSA) and Curve25519 (ed25519). | https://www.w3.org/TR/vc-di-eddsa/ | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-05-18 | |||||||||||||||||||||||||||||
| 87 | VCs Development | VCWG | BBS Cryptosuite v2023 | This specification describes the BBS+ Signature Suite created in 2023 for the Data Integrity specification. The Signature Suite utilizes BBS+ signatures to provide the capability of zero knowledge proof disclosures. | https://www.w3.org/TR/vc-di-bbs/ | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-05-18 | |||||||||||||||||||||||||||||
| 88 | VCs Development | VCWG | JSON Web Signatures for Data Integrity Proofs | This specification describes a JSON Web Signature Suite created in 2020 for the Verifiable Credentials Data Integrity Proof specification. The Signature Suite utilizes Detached JWS signatures to provide support for a subset of the digital signature algorithms registered with IANA. | https://www.w3.org/TR/vc-jws-2020/ | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-01-27 | |||||||||||||||||||||||||||||
| 89 | VCs Development | VCWG | Securing Verifiable Credentials using JSON Web Tokens | This specification defines how Verifiable Credentials can be represented as JSON Web Tokens (JWT) [RFC7519] and secured using JSON Web Signatures (JWS) [RFC7515]. | https://www.w3.org/TR/vc-jwt/ | Specification | Working Draft | Verifiable Credentials Working Group | Cryptography | Verifiable Credentials WG | 2023-05-15 | |||||||||||||||||||||||||||||
| 90 | VCs Development | W3C | CCG | https://w3c-ccg.github.io/ | Verifiable Credentials, Decentralized Identifiers | Credentials Community Group | The mission of the Credentials Community Group is to explore the creation, storage, presentation, verification, and user control of credentials. We focus on a verifiable credential (a set of claims) created by an issuer about a subject—a person, group, or thing—and seek solutions inclusive of approaches such as: self-sovereign identity; presentation of proofs by the bearer; data minimization; and centralized, federated, and decentralized registry and identity systems. Our tasks include drafting and incubating Internet specifications for further standardization and prototyping and testing reference implementations. | https://www.w3.org/community/credentials/ | Working Group | Credentials Community Group | Credentials Community Group | 2014-08-19 | https://github.com/w3c-ccg/community | https://lists.w3.org/Archives/Public/public-credentials/ | ||||||||||||||||||||||||||
| 91 | VCs Development | CCG | W3C CCG meeting transcripts | This repo contains the meeting archives for the W3C-CCG (Credentials Community Group), including transcripts based on the IRC logs and audio files for our regular meetings, ancillary material such as slide presentations, etc. The archives for 2014-2019 can be found here. | COMMUNITY: W3C Credentials Community Group meeting transcripts - GitHub - w3c-ccg/meetings: COMMUNITY: W3C Credentials Community Group meeting transcripts | https://github.com/w3c-ccg/meetings | Page | Credentials Community Group | ||||||||||||||||||||||||||||||||
| 92 | VCs Development | CCG | RWOT, IIW | W3C CCG announcements | Announcements and events associated with the W3C Credentials CG | https://github.com/w3c-ccg/announcements | Page | Credentials Community Group | ||||||||||||||||||||||||||||||||
| 93 | VCs Development | CCG | W3C CCG Work Item Process | This lets you write your specs in markdown, or technically bikeshed -- a markdown document, with special extensions understood by the bikeshed tool. The bikeshed tool is run on-commit via the spec-prod github action, generating the familiar "spec looking" ReSpec format. ReSpec is just html with a javascript ReSpec library. | https://github.com/w3c-ccg/workitem-process | Page | Credentials Community Group | |||||||||||||||||||||||||||||||||
| 94 | VCs Development | CCG | Global Open Badges Workgroup, Verifiable Credentials WG, Credentials Commiunity Group, Schema.org | WORK ITEM: Drafts and Ideas of Educational and Occupational Verifiable Credentials - w3c-ccg/edu_occ_verifiable_credentials | Work on describing credentials is occurring within the IMS Global Open Badges Workgroup, W3C Verifiable Credentials Working Group, W3C Credentials Commiunity Group, Educational and Occupational Credentials in Schema.org Community Group, and Credential Engine/CTDL.<br><br>This effort will result in requirements, use cases, and/or draft specs to be formalized in the appropriate standards group | https://github.com/w3c-ccg/edu_occ_verifiable_credentials | Code | Credentials Community Group | Credentials Community Group | |||||||||||||||||||||||||||||||
| 95 | VCs Development | CCG | WORK ITEM: Verifiable Credentials Examples | This GitHub Pages Website hosts example credentials, as well as documents needed to construct them. When contributing an example, you are encouraged to provide everything needed to generate an verify a credential. Do your best not to include ANY broken links or missing documentation. If possible, try to make the credential id resolvable as well. | https://github.com/w3c-ccg/vc-examples | Code | Credentials Community Group | Credentials Community Group | ||||||||||||||||||||||||||||||||
| 96 | VCs Development | CCG | Verifiable Credentials Extension Registry | Verifiable Credentials Extension Registry | - This document contains a list of all known Verifiable Credential extensions and their associated specifications. Credentials Community Group | https://w3c-ccg.github.io/vc-extension-registry/ | Report | draft | Credentials Community Group | Credentials Community Group | 2022-11-14 | |||||||||||||||||||||||||||||
| 97 | VCs Development | CCG | Verifiable Credentials Extension Registry | Markus Sabadello | Ed25519Signature2018 | This specification describes a standard signature suite created in 2018 for the Linked Data Signatures [LD-SIGNATURES] specification. It uses the RDF Dataset Normalization Algorithm [RDF-DATASET-NORMALIZATION] to transform the input document into its canonical form. It uses SHA-256 [RFC6234] as the message digest algorithm and Ed25519 [ED25519] as the signature algorithm. | https://w3c-ccg.github.io/lds-ed25519-2018/ | Report | draft | Credentials Community Group | Proof Methods | Credentials Community Group | 2021-07-23 | |||||||||||||||||||||||||||
| 98 | VCs Development | CCG | Verifiable Credentials Extension Registry | Manu Sporny, Dave Longley | RsaSignature2018 | This specification describes the RSA Signature Suite created in 2018 for the Linked Data Signatures [LD-SIGNATURES] specification. It uses the RDF Dataset CANONICALIZATION Algorithm [RDF-DATASET-CANONICALIZATION] to transform the input document into its canonical form. It uses SHA-256 [RFC6234] as the message digest algorithm and the RS256 algorithm defined in JSON Web Signatures [RFC7515] as the signature algorithm. | https://w3c-ccg.github.io/lds-rsa2018/ | Report | draft | Credentials Community Group | Proof Methods | Credentials Community Group | 2020-05-26 | |||||||||||||||||||||||||||
| 99 | VCs Development | CCG | Verifiable Credentials Extension Registry | Manu Sporny, Dave Longley | CredentialStatusList2017 | A simple list-based mechanism for publishing and checking the status of a credential | https://w3c-ccg.github.io/vc-csl2017/ | Report | Credentials Community Group | Status Methods | Credentials Community Group | 2020-12-29 | ||||||||||||||||||||||||||||
| 100 | VCs Development | CCG | Ecdsa Secp256k1 Signature 2019 | This specification describes the Ecdsa Secp256k1 Signature created in 2019 for the Linked Data Signatures specification | https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/ | Code | Draft | Credentials Community Group | 2020-04-08 | |||||||||||||||||||||||||||||||
| 101 | VCs Development | CCG | Verifiable Credential JSON Schemas | The [VC_DATA_MODEL](https://www.w3.org/TR/vc-data-model/) specifies the models used for Verifiable Credentials and Verifiable Presentations, and explains the relationships between three parties: issuer, holder, and verifier. A critical piece of infrastructure out of the scope of those specifications is the Credential Schema. | A mechanism to use JSON Schemas with Verifiable Credentials - GitHub - w3c/vc-json-schema: A mechanism to use JSON Schemas with Verifiable Credentials | https://github.com/w3c-ccg/vc-json-schemas | Code | Credentials Community Group | 2023-05-24 | |||||||||||||||||||||||||||||||
| 102 | VCs Development | CCG | Traceability Vocabulary v0.1 | This specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain and other traceability information, similar to what is often referred to as "provenance", including country of origin, chemical properties, mechanical properties, and other attributes of products and materials. VCs using these terms can then be used to help determine the legitimacy of organizations participating in global trade and the status of the products and materials described therein | https://w3c-ccg.github.io/traceability-vocab/ | https://w3c-ccg.github.io/traceability-vocab/resources/product-identifier-verification-from-identification-key-license.png | Specification | v0.1 | Credentials Community Group | Credentials Community Group | 2023-05-23 | |||||||||||||||||||||||||||||
| 103 | VCs Development | DIF | Claims and Credentials Working Group | Join this group to contribute to the standards and technology that create, exchange, and verify claims and credentials in a decentralized identity ecosystem. For example, a cryptographically verifiable credential that proves an individual has a college degree or is of a certain age. Our members focus on specs that are vendor agnostic and based on industry standards. | https://identity.foundation/working-groups/claims-credentials.html | page | Claims and Credentials Working Group | 2020-09-18 | ||||||||||||||||||||||||||||||||
| 104 | VCs Development | DIF | presentation-exchange | Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions | Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission) - GitHub - decentralized-identity/presentation-exchange: Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission) | https://github.com/decentralized-identity/presentation-exchange | Code | Claims and Credentials Working Group | 2023-05-31 | |||||||||||||||||||||||||||||||
| 105 | VCs Development | DIF | presentation-request | Requirements Analysis and Protocol Design for a VC Presentation Request Format | Requirements Analysis and Protocol Design for a VC Presentation Request Format - GitHub - decentralized-identity/presentation-request: Requirements Analysis and Protocol Design for a VC Presentation Request Format | https://github.com/decentralized-identity/presentation-request | Code | Claims and Credentials Working Group | 2020-01-08 | |||||||||||||||||||||||||||||||
| 106 | VCs Development | DIF | Credential Manifest | Credential Manifests do not themselves define the contents of the output credential(s), the process the Issuer uses to evaluate the submitted inputs, or the protocol Issuers, Subjects, and their User Agents rely on to negotiate credential issuance. Instead, Credential Manifests are a data model for issuers to publish and/or send individually to would-be holders, allowing the software of the latter to understand and negotiate an issuance process. | https://identity.foundation/credential-manifest/ | page | Claims and Credentials Working Group | 2023-05-04 | ||||||||||||||||||||||||||||||||
| 107 | VCs Development | Personal | Kyle Den Hartog | Example Design of an Authorization System with Verifiable Credentials and the Tradeoffs | The primary focus of this blog post is to highlight the different problems that are likely to occur when going down the path of building an authorization system with verifiable credentials. I’ll be sure to keep things at a higher level so that anyone can understand these tradeoffs, but take you through the details that would be thought through by an architect designing the system. | https://kyledenhartog.com/example-authz-with-VCs/ | Post | Development | 2021-06-22 | |||||||||||||||||||||||||||||||
| 108 | VCs Development | 51 Nodes | Indexing and Querying Revoked Verifiable Credentials | this article describes a simple approach to revoke verifiable credentials and a decentralized and efficient way to index and query those revoked credentials using the [Graph protocol](https://thegraph.com/en/). | Due to its immutability and censorship resistance, the Blockchain seems to be a suitable place to manage identities and credentials. However, querying the data on the blockchain in a trusted and… | https://medium.com/51nodes/indexing-and-querying-revoked-verifiable-credentials-e229dc2781d4 | Post | Development | 2022-07-01 | |||||||||||||||||||||||||||||||
| 109 | VCs Development | CCG Mailing List | Nikos Fotiou | VC Issuance based on OAuth 2.0 | We design, implement, and evaluate a solution for achieving continuous authorization of HTTP requests exploiting Verifiable Credentials (VCs) and OAuth 2.0. Specifically, we develop a VC issuer that acts as an OAuth 2.0 authorization server, a VC verifier that transparently protects HTTP-based resources, and a VC wallet implemented as a browser extension capable of injecting the necessary authentication data in HTTP requests without needing user intervention. | https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0084.html | Discussion | Development | Credentials Community Group | 2022-04-14 | ||||||||||||||||||||||||||||||
| 110 | VCs Development | CCG Mailing List | Orie Steele | Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API | [https://github.com/OR13/GNARLY](https://github.com/OR13/GNARLY) (while we wait for a better name...)<br><br>This demo API and Spec has a number of improvements over the current<br><br>VC-HTTP-API, including tested support for VC-JWT, JsonWebSignature2020 and<br><br>BBS+ Selective Disclosure Presentation Exchange. | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0313.html | Discussion | Development | Credentials Community Group | 2021-07-31 | ||||||||||||||||||||||||||||||
| 111 | VCs Development | CCG Mailing List | https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0141.html | Joe Andrieu | Updated VC-API diagram for Supply Chain flow | I updated the supply chain version of the data flow diagram for verification. | https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0141.html | https://i.imgur.com/mH5TBtU.png | Discussion | Development | Credentials Community Group | 2021-09-28 | ||||||||||||||||||||||||||||
| 112 | VCs Development | CCG Mailing List | Manu Sporny | re: VC API: handling large documents client to server | Typical solutions to this problem require that you put the binary data outside of the VC, if at all possible. This works well for common static images such as logos. It is also possible to split the VC into two VCs... one with the machine-readable data from the issuer (with a digital signature) and one with the image data from any source (without a digital signature, since, if hashlinked, the signature will verify the validity of the image data). That latter approach can be more privacy preserving AND more complex than many might feel is necessary. | https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0035.html | Discussion | Development | Credentials Community Group | 2022-02-10 | ||||||||||||||||||||||||||||||
| 113 | VCs Development | CCG Mailing List | Manu Sporny | VC-API interoperability test suites ready for experimental integration | * [The VC API test suite for basic issuer interop is here](https://w3c-ccg.github.io/vc-api-issuer-test-suite/)<br>* [The VC API test suite for basic verifier interop is here](https://w3c-ccg.github.io/vc-api-verifier-test-suite/)<br>* [The Data Integrity test suite for Ed25519Signature2020 interop is here](https://w3c-ccg.github.io/di-ed25519-test-suite/) | https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0126.html | Discussion | Development | Credentials Community Group | 2022-04-26 | ||||||||||||||||||||||||||||||
| 114 | VCs Development | CCG Mailing List | Manu Sporny | Cross-industry VC API test suite achieves first multi-vendor interop for issue/verify | We are happy to announce today that we have our first demonstration of cross-vendor interoperability between Danube Tech and Digital Bazaar for the VC Issuer API and VC Verifier API. The test suites test the OAS definition files (which are used to generate the specification):<br>* [2.1 Verify Credential - Data Integrity](https://w3c-ccg.github.io/vc-api-verifier-test-suite/#Verify%20Credential%20-%20Data%20Integrity)<br>* [2.1 Issue Credential - Data Integrity](https://w3c-ccg.github.io/vc-api-issuer-test-suite/#Issue%20Credential%20-%20Data%20Integrity) | https://lists.w3.org/Archives/Public/public-credentials/2022May/0041.html | Discussion | Development | Credentials Community Group | 2022-05-18 | ||||||||||||||||||||||||||||||
| 115 | VCs Development | CCG Mailing List | Joe Andrieu | Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021] | a. *Holder* The entity who holds the VC once issued and later presents it for verification.<br>b. *Holder Application *The software or service that allows holders to manage their credentials. Often called a wallet. For symmetry, it could be called a Holder Service.<br>c. *Storage Service *The software or service that actually stores VCs long term (on behalf of the holder)<br>d. *Issuer Role* The website or software that provides issuing functionality to a holder on behalf of that issuer)<br>e. *Issuer Service* Software or service that actually signs VCs and VPs) This component is used by both the issuer (to mint VCs) and the holder (to create VPs for presentation)<br>f. *Verifier Role* The website or software that uses a Verification Service as part of its decision making process for providing services to holders.<br>g. *Verifier Service *The software or service that verifies VCs and VPs by checking proofs and checking status. | https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0231.html | https://i.imgur.com/4hCNLVA.png | Discussion | Development | Credentials Community Group | 2021-08-16 | |||||||||||||||||||||||||||||
| 116 | VCs Development | CCG Mailing List | Brian Richter | Issuer API Cross Trust Boundary Scoping - VC-HAPI (f.k.a. VC-HTTP-API) | I think I'm starting to understand how RAR fits into this picture. This decision can be made for us by punting the question to the authorization process entirely. With RAR we can force the user to authorize for the actual subject they are issuing the credential about. Is Alice authorized to issue VCs with claims about did:example:12345? To answer that question Alice asks for a token with the following RAR request | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0263.html | Discussion | Development | Credentials Community Group | 2021-07-24 | ||||||||||||||||||||||||||||||
| 117 | VCs Development | CCG Mailing List | Justin Richer | RAR Structures for VC HTTP API | It seemed like a good idea when I first invented it a decade ago:[https://blue-button.github.io/blue-button-plus-pull/#scopes](https://blue-button.github.io/blue-button-plus-pull/#scopes) or when it got pulled into other efforts like [https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html](https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html)… and Orie even suggested the following set of parameterized scopes for this API:<br>'create:credentials': Grants permission to create credentials<br>'derive:credentials': Grants permission to derive credentials<br>'create:presentations': Grants permission to create presentations<br>'verify:presentations': Grants permission to verify presentations<br>'exchange:presentations': Grants permission to exchange presentations<br>So what’s the problem? I can say with full confidence after years of experience building and deploying systems to support parameterized scopes like this that they are fragile, awkward, and lead to insecure corner cases. | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0208.html | Discussion | Development | Credentials Community Group | 2021-07-21 | ||||||||||||||||||||||||||||||
| 118 | VCs Development | CCG Mailing List | Manu Sporny | Bikeshed: Renaming the VC HTTP API | the fundamental issue is that stringing a bunch of consonants together ("HTTP") rarely leads to something easy to say in conversation. | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0131.html | Discussion | Development | Credentials Community Group | 2021-07-17 | ||||||||||||||||||||||||||||||
| 119 | VCs Development | CCG Mailing List | Kerri Lemoie | Question About Signatures & Contexts | Is a VC still considered to be valid if it contains fields that are not described in its context file(s)? Does it depend on the signature type? | https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0290.html | Discussion | Development | Credentials Community Group | 2021-07-30 | ||||||||||||||||||||||||||||||
| 120 | VCs Development | CCG Mailing List | Bob Wyman | Any Good use case of PAM (Privileged account Management) using Vcs | A common example of this is when someone uses a "Power of Attorney," to sign a contract. When they do, they typically sign documents with their own names and an annotation "on behalf of," "for," or "by power of attorney," they don't forge the signature of the one who granted the power of attorney. | https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0028.html | Discussion | Development | Credentials Community Group | 2021-11-06 | ||||||||||||||||||||||||||||||
| 121 | 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 | |||||||||||||||||||||||||||||||
| 122 | 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 | ||||||||||||||||||||||||||||||
| 123 | 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 | ||||||||||||||||||||||||||||||
| 124 | 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 | |||||||||||||||||||||||||||||
| 125 | 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 | ||||||||||||||||||||||||||||||
| 126 | 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 | ||||||||||||||||||||||||||||||
| 127 | 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 | ||||||||||||||||||||||||||||||
| 128 | 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 | ||||||||||||||||||||||||||||
| 129 | 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 | |||||||||||||||||||||||||||
| 130 | 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 | |||||||||||||||||||||||||||||||
| 131 | Decentralized Identifiers | DIDWG | https://w3c-ccg.github.io/did-wg-charter/ | W3C | Decentralized Identifier Working Group | The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications. | https://www.w3.org/2019/did-wg/ | Working Group | Main | 2019-05-31 | https://github.com/w3c/did-wg | |||||||||||||||||||||||||||||
| 132 | Decentralized Identifiers | DIDWG | Decentralized Identifier (DID) 1.0 Specification - Data Model and Syntax | This document specifies the DID syntax, a common data model, core properties, serialized representations, DID operations, and an explanation of the process of resolving DIDs to the resources that they represent. | Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. | https://w3c.github.io/did-core/ | https://w3c.github.io/did-core/diagrams/did_detailed_architecture_overview.svg | Specification | Main | Decentralized Identifier WG | 2022-07-19 | https://github.com/w3c/did-core | ||||||||||||||||||||||||||||
| 133 | Decentralized Identifiers | DIDWG | DID Specification Registries | This document serves as an official registry for all known global parameters, properties, and values used by the Decentralized Identifier ecosystem. | https://w3c.github.io/did-spec-registries/ | Registry | Main | DID Working Group | 2023-05-14 | https://github.com/w3c/did-spec-registries | ||||||||||||||||||||||||||||||
| 134 | Decentralized Identifiers | Personal | Adam Powers | Understanding Decentralized IDs (DIDs) | This article starts off with an overview of DIDs, DID Documents, Verifiable Claims and DIDAuth — basically laying out how the technology works. It then explores the economics of DIDs to try and understand what problems they propose to solve, for whom, and how they go about solving them. | Decentralized identifiers (DIDs) came to my attention at the last Internet Identity Workshop (IIW), where it seemed like 30% of all presentations were about DIDs. I feel like I’m a latecomer to the… | https://medium.com/@adam_14796/understanding-decentralized-ids-dids-839798b91809 | https://miro.medium.com/v2/resize:fit:1200/1*lHXvR78dlN63nbyYKu7z_Q.png | Post | Explainer | 2018-06-02 | |||||||||||||||||||||||||||||
| 135 | Decentralized Identifiers | Personal | https://docs.google.com/document/d/1Ym85y_bDVN9xkRZ-oD-zlUUIeZjVGWNihfZBk2GQidk/edit | Michael Herman | What is a DID? The Path from an id (DID) to a Real-Life Subject | The following graphic illustrates the path (flow) of a client app trying to: a) communicate/interact with, and/or b) access the metadata about a real-life subject by using a Decentralized Identifier (id (DID)).<br>That is, in (almost) 10 steps or less, how to you get from an id (DID) attribute on the left to a Real-Life Subject on the right? | Hyperledger Indy/Sovrin/DID Comprehensive Architecture Reference Model (INDY ARM) - Draft document for discussion purposes - indy-arm/README.md at master · mwherman2000/indy-arm | https://github.com/mwherman2000/indy-arm/blob/master/README.md#appendix-e---did-resolution-path-from-a-did-to-a-real-life-subject- | Page | Explainer | 2019-05-19 | |||||||||||||||||||||||||||||
| 136 | Decentralized Identifiers | Affinidi | Demystifying Decentralized Identifiers (DIDs) | - Does not require a centralized registration authority<br>- Many DIDs use the distributed ledger technology or any other decentralized network, though it is not mandatory<br>- It is a permanent identifier because it does not depend on a single third-party or centralized registry for its existence.<br><br>- Can be cryptographically verified<br>- They connect a DID subject (the entity identified by the DID) with a DID document (a set of data that describes the DID subject) to enable the subject to have trustable interactions.<br>- They are interoperable and portable, provided they conform to the existing standards laid down by W3C | Self-Sovereign Identity (SSI) gives users control over how their data is stored and shared and a building block of SSI is Decentralized Identifiers (DIDs). | https://academy.affinidi.com/demystifying-decentralized-identifiers-dids-2dc6fc3148fd | https://miro.medium.com/v2/resize:fit:1200/1*D5oqVHELQBRxW4AcasQepA.png | Post | Explainer | 2021-05-05 | ||||||||||||||||||||||||||||||
| 137 | Decentralized Identifiers | Hackernoon | Decentralized Identifiers (DIDs) - A Deeper Dive | The same way the SSL/TLS protocol changed internet use forever by opening a gate to the world of encrypted Web traffic, which is the basis for the protocol that keeps the web safe and secure HTTPS; the same way will DIDs enhance the verification process in world of blockchain, such as decentralized finance. | https://hackernoon.com/decentralized-identifiers-dids-a-deeper-dive-04383442 | Post | Explainer | 2021-04-26 | ||||||||||||||||||||||||||||||||
| 138 | Decentralized Identifiers | Elastos | Decentralized Identity: Why Are DIDs The Future of Digital Identity Management? | You need to create separate digital identity credentials for each one. Only after you’ve registered with them can you access the services of each organization. And don’t forget: all free-to-use apps and websites control the storage of your data and are happy to sell access to it to third parties for profit. That’s literally their business plan: they understand the value of your data and how they can monetize it. | We have more accounts than we can recall, and each one stores our data on central servers. With a DID (decentralized identity), you can own your own data. Discover why blockchain-based digital identities are the future of digital identity management... | https://elastos.info/decentralized-identity-dids/ | Post | Explainer | 2021-10-14 | |||||||||||||||||||||||||||||||
| 139 | Decentralized Identifiers | Impervious | Decentralized Identifiers: Implications for Your Data, Payments and Communications | Through the DID Specification, service endpoints and DIDComm, Impervious has interlaced DIDs with Bitcoin Lightning, IPFS, WebRTC and resilient relays to introduce a new peer-to-peer internet standard with practical applications for mitigating censorship and surveillance risk. | https://newsletter.impervious.ai/decentralized-identifiers-implications-for-your-data-payments-and-communications-2/ | Post | Explainer | 2022-03-22 | ||||||||||||||||||||||||||||||||
| 140 | Decentralized Identifiers | WebOfTrustInfo | rwot02-2020 | DID Whitepaper | A DID architecture should focus on the set of components that Mr. Gupta refers to as "the minimum required for people to be able to do business (or other critical functions) together".<br><br>**A Decentralized Identifier (DID) Registry and Discovery Service**<br><br>This "minimum required" is defined by a union of the proposed requirements identified by the W3C Credential Community Group, the XDI.org Registry Working Group, and the Rebooting the Web of Trust group. It consists of three functions that can be addressed by a combination of blockchain and DHT technology:<br><br>- A DID registration function<br>- A discovery function that enables looking up a registered DID in the blockchain<br>- A master key recovery function | https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/topics-and-advance-readings/DID-Whitepaper.md | Paper | Literature | 2016-05-18 | |||||||||||||||||||||||||||||||
| 141 | Decentralized Identifiers | IETF | A Universally Unique IDentifier (UUID) URN Namespace | A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms | https://www.ietf.org/rfc/rfc4122.txt | Specification | Literature | 2005-07 | ||||||||||||||||||||||||||||||||
| 142 | Decentralized Identifiers | 2ndQuadrant | Tomas Vondra | All you need to know about sequential UUID generators | UUIDs are a popular identifier data type – they are unpredictable, and/or globally unique (or at least very unlikely to collide) and quite easy to generate. Traditional primary keys based on sequences won’t give you any of that, which makes them unsuitable for public identifiers, and UUIDs solve that pretty naturally. | sequential-uuids extension introduces generators of sequential UUIDs, addressing some of the common issues - random I/O patterns and WAL write amplification | http://web.archive.org/web/20190320121253/https://blog.2ndquadrant.com/sequential-uuid-generators/ | Post | Literature | 2019-03-02 | ||||||||||||||||||||||||||||||
| 143 | Decentralized Identifiers | WebofTrustInfo | Drummond Reed, Manu Sporny, others | rwot05-boston | DID Primer | At a superficial level, a decentralized identifier (DID) is simply a new type of globally unique identifier with special features designed for blockchains. But at a deeper level, DIDs are actually the tip of the iceberg -- or the tip of the spear -- of an entirely new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. This decentralized public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world). | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/did-primer.md | Paper | Literature | 2017-10-06 | ||||||||||||||||||||||||||||||
| 144 | Decentralized Identifiers | WebofTrustInfo | Drummond Reed, Manu Sporny, others | rwot07-toronto | DID Primer Extended | - Background on the origin of DIDs and the DID specification.<br>- How DIDs differ from other globally-unique identifiers.<br>- How the syntax of DIDs can be adapted to work with any modern blockchain.<br>- How DIDs resolve to DID documents containing public keys and service endpoints.<br>- The key role that DID methods play in the implementation of DID infrastructure. | https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/topics-and-advance-readings/did-primer-extended.md | Paper | Literature | 2019-02-14 | ||||||||||||||||||||||||||||||
| 145 | Decentralized Identifiers | DIDWG | Markus Sabadello | Decentralized Identifiers | 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<br>- did:sov:3k9dg356wdcj5gf2k9bw8kfg7a<br>- Modular specifcation using “methods”:<br>- did:sov, did:btcr, did:v1, did:uport, ...<br>- Can be pairwise unique for each relationship<br>- Resolution: DID → DID Document | https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf | Presentation | Literature | DID Working Group | 2018-04-17 | |||||||||||||||||||||||||||||
| 146 | Decentralized Identifiers | WebofTrustInfo | Decentralized Identifiers | rwot02-2020 | Requirements for DIDs | Respect Network is conducting a research project for the U.S. Department of Homeland Security, HSHQDC-16-C-00061, to analyze the applicability of blockchain technologies to a decentralized identifier system. Our thesis is that blockchains, or more generically distributed ledgers, are a potentially powerful new tool for “identity roots” — the starting points for an Internet identity. However “blockchain identity” may not fully address the core security and privacy principles needed in a complete identity system. In this case DIDs — Decentralized Identifiers rooted on a distributed ledger — may end up being a foundational building block for higher level identity management solutions. | https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/final-documents/requirements-for-dids.pdf | Paper | Literature | 2016-08-24 | ||||||||||||||||||||||||||||||
| 147 | Decentralized Identifiers | WebofTrustInfo | Decentralized Identifiers | rwot07-toronto | DIDs in DPKI | - DPKI stands for Decentralized Public-key Infrastructure<br>- DPKI seeks to serve as an improved alternative/replacement for X.509 (that thing securing today's Internet)<br>- DPKI changes the web's security model from 1000s of single-points-of-failure to decentralized consensus groups that create namespaces (sorta like what blockchains do!)<br>- DPKI is not a blockchain — it's a protocol for securely accessing blockchains and similar decentralized consensus systems<br>- DPKI has Top-Level Domains (TLDs) representing different blockchains (e.g. .eth, .bit, .id etc.) | https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/dids-in-dpki.md | Paper | Literature | 2018-08-23 | ||||||||||||||||||||||||||||||
| 148 | Decentralized Identifiers | SRI International, NIST, FIMSA | Decentralized Identifiers | Cryptography Review of W3C VC Data Model and DID Standards and Implementation Recommendations | Cryptography used by U.S. government entities in operational systems must conform to relevant federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography. As part of its in-depth technical due-diligence to enable operational capabilities for DHS/CBP, DHS/PRIV and DHS/USCIS, the U.S. Department of Homeland Security’s Silicon Valley Innovation Program (SVIP) sponsored independent nonprofit research center SRI International to conduct a cryptographic review of the W3C Verifiable Credentials Data Model and W3C Decentralized Identifiers standards. The review provided constructive feedback and recommendations for technology developers and W3C standards developers to increase their level of compliance with federal government standards. | https://web.archive.org/web/20230319062836/https://www.csl.sri.com/papers/vcdm-did-crypto-recs/ | Paper | Literature | 2023-03-19 | |||||||||||||||||||||||||||||||
| 149 | Decentralized Identifiers | DIDWG | Decentralized Identifier Use Cases and Requirements v1.0 | This document sets out use cases and requirements for a new kind of identifier that meets all these basic requirements: decentralized, persistent, cryptographically verifiable, resolvable | https://w3c.github.io/did-use-cases/ | https://w3c.github.io/did-use-cases/images/didUse.svg | Draft | Literature | Decentralized Identifier WG | 2021-06-16 | https://github.com/w3c/did-use-cases | |||||||||||||||||||||||||||||
| 150 | Decentralized Identifiers | DIDWG | Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes | DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may express cryptographic material, verification methods, and/or service endpoints. These provide a set of mechanisms which enable a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject.<br><br>This document specifies a common data model, format, and operations that all DIDs support. | https://www.w3.org/2019/08/did-20190828/ | Report | Literature | Decentralized Identifier WG | 2019-09-13 | |||||||||||||||||||||||||||||||
| 151 | Decentralized Identifiers | DIDWG | DID Implementation Guide | This document acts as a technical narrative for the implementation of DID methods and is expected to cover many topics related to that subject that a developer may wish to consider, including guidance around implementation details that may also be used for third party evaluation of an authored DID method via the DID-RUBRIC. | https://w3c.github.io/did-imp-guide/ | https://w3c.github.io/did-imp-guide/diagrams/representation-specific-and-foreign-entries.png | Note | Literature | DID Working Group | 2021-11-04 | https://github.com/w3c/did-imp-guide | |||||||||||||||||||||||||||||
| 152 | Decentralized Identifiers | DIDWG | W3C DID Test Suite and Implementation Report | This document describes the did core test suite, and summarizes the latest test results. | https://w3c.github.io/did-test-suite/ | Internal | Literature | DID Working Group | 2023-01-17 | https://github.com/w3c/did-test-suite | ||||||||||||||||||||||||||||||
| 153 | Decentralized Identifiers | DIDWG | W3C Decentralized Characteristics Rubric v1.0 | This rubric presents a set of criteria which an Evaluator can apply to any DID Method based on the use cases most relevant to them. We avoid reducing the Evaluation to a single number because the criteria tend to be multidimensional and many of the possible responses are not necessarily good or bad. It is up to the Evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs. | https://w3c.github.io/did-rubric/ | Internal | Literature | DID Working Group | 2022-01-11 | https://github.com/w3c/did-rubric | ||||||||||||||||||||||||||||||
| 154 | Decentralized Identifiers | DIDWG | Well Known DID Configuration | The DID Configuration resource provides proof of a bi-directional relationship between the controller of an origin and a DID via cryptographically verifiable signatures that are linked to a DID's key material. This document describes the data format of the resource and the resource location at which origin controllers can publish their DID Configuration. | This repo contains proposals and links to proposals for .well-known uris related to DIDs, Hubs and Agents. See IETF RFC5785 for more details on Defining Well-Known Uniform Resource Identifiers. | https://identity.foundation/.well-known | Specification | Supporting | DID Working Group | 2020-12-10 | https://github.com/decentralized-identity/.well-known | |||||||||||||||||||||||||||||
| 155 | Decentralized Identifiers | CCG | Decentralized Identifier Resolution (DID Resolution) v0.3 | DID resolution is the process of obtaining a DID document for a given DID. This is one of four required operations that can be performed on any DID ("Read"; the other ones being "Create", "Update", and "Deactivate"). The details of these operations differ depending on the DID method. Building on top of DID resolution, DID URL dereferencing is the process of retrieving a representation of a resource for a given DID URL. Software and/or hardware that is able to execute these processes is called a DID resolver. | https://w3c-ccg.github.io/did-resolution/ | https://w3c-ccg.github.io/did-resolution/diagrams/https-dereference-example-1.png | Specification | Supporting | Credentials Community Group | 2023-01-18 | https://github.com/w3c-ccg/did-resolution | |||||||||||||||||||||||||||||
| 156 | Decentralized Identifiers | GoDiddy | https://iiw.idcommons.net/2C/_godiddy.com_-_Universal_DID_Services | Markus Sabadello | godiddy.com - Universal DID Services | Basic functions are creating, resolving, updating, and deactivating DIDs across multiple DID methods and networks. Advanced functions include key management, search, transfer of DIDs, lookup of historical DID document versions, notification of DID-related events, and more. | https://godiddy.com | site | Supporting | 2021-05-06 | https://docs.godiddy.com/ | https://api.godiddy.com/ | ||||||||||||||||||||||||||||
| 157 | Decentralized Identifiers | IDCommons | Markus Sabadello | Standard Interfaces for DID Create/Update/Deactivate | - There is an attempt to specify abstract interfaces if you want to Create/Update/Deactivate a did that could be implemented for all did methods.<br>- The idea of this specification is to provide a standard with the same assumptions as with resolution. It should be in an abstract level, meaning it should specify the inputs and outputs of creating/updating/deactivating a did but not how it should be implemented. | https://iiw.idcommons.net/3C/_Standard_Interfaces_for_DID_Create/Update/Deactivate | Session Notes | Supporting | 2021-07-17 | |||||||||||||||||||||||||||||||
| 158 | Decentralized Identifiers | W3C | DID test suite | DID test suite is not for runtime, but the Universal Resolver could do a few simple checks on a driver's responses. But there's also a philosophical question: Should the Universal Resolver be "allowed" to check and potentially transform driver responses, or should it just "pass through" everything that comes from a driver? | https://github.com/w3c/did-test-suite | Code | Supporting | 2023-01-17 | ||||||||||||||||||||||||||||||||
| 159 | Decentralized Identifiers | Personal | Micheal Herman | BlueToque Tools Toolkit | BlueToque Tools is a collection of software tools for working with DID Method Namespaces, DID Identifiers, DID Documents, DID Agent Service Endpoints, DID Agent Servers, DID Agent Clusters, and DID Objects (the 7 DIDs). The flagship tool is didlang, a language for interactively working with the 7 DIDs. | https://github.com/mwherman2000/BlueToqueTools | Code | Supporting | 2022-12-06 | |||||||||||||||||||||||||||||||
| 160 | DID Methods | Legendary Requirements | did:directory | DID methods are the magic ingredient that gives DIDs their flexibility. Before creating any specific DID, you first choose a DID method, which determines how you perform the create, read, update, and deactivate operations on a DID of that method.<br><br>Once created, each DID includes the name of its method in the identifier itself, so that when you use the DID, others know how to retrieve the associated DID Document that contains the cryptographic material for secure interactions.<br><br>Different DID methods use different underlying mechanisms with different performance, security, and privacy tradeoffs. | https://diddirectory.com/ | Directory | Main | |||||||||||||||||||||||||||||||||
| 161 | DID Methods | DIDWG | Decentralized Identifiers | DID Specification Registries | This table summarizes the DID method specifications currently in development. The links will be updated as subsequent Implementer’s Drafts are produced. | https://w3c-ccg.github.io/did-method-registry/#the-registry | registry | Main | DID Working Group | 2023-05-14 | ||||||||||||||||||||||||||||||
| 162 | DID Methods | Transmute | Margo Johnson | Decentralized Identifiers | DID:Customer | While we are committed to providing optionality to our customers, it’s equally important to communicate the selection criteria behind these options so that customers can consider the tradeoffs of underlying DID-methods alongside the problem set they’re solving for. | Transmute builds solutions that solve real business problems. For this reason, we support a number of different decentralized identifier (DID) methods. While we are committed to providing optionality… | https://medium.com/transmute-techtalk/did-customer-4ca8b7957112 | Post | Main | 2020-10-30 | |||||||||||||||||||||||||||||
| 163 | DID Methods | WebOfTrustInfo | Joe Andrieu, Shannon Appelcline, Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, Oliver Terbu, Kai Wagner | Decentralized Identifiers | rwot9-prague | A Rubric for Decentralization of DID Methods | The communities behind Decentralized Identifiers (DIDs) bring together a diverse group of contributors, who have decidedly different notions of exactly what “decentralization” means. For some, the notion of a DID anchored to DNS is anathema, for others, DIDs that cannot be publicly verified are problematic. This debate about decentralization is a continuation of a similar, ongoing argument in cryptocurrency circles: the question of whether or not bitcoin or ethereum is more decentralized is a nearly endless source of argument. Rather than attempting to resolve this potentially unresolvable question, we propose a rubric — which is a scoring guide used to evaluate performance, a product, or a project — that teaches how to evaluate a given DID method according to one’s own requirements. Our goal is to develop a guide that minimizes judgment and bias. Rather than advocating particular solutions, the rubric presents a series of criteria which an evaluator can apply to any DID method based on their particular use cases. We also avoid reducing the evaluation to a single number because the criteria tend to be multidimensional and many of the options are not necessarily good or bad: it is the obligation of the evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs. Finally, this rubric allows evaluating aspects of decentralization of a DID method, but it is not exhaustive, and does not cover other issues that may affect selection or adoption of a particular method, such as privacy or efficiency. | RWOT9 in Prague, The Czech Republic (September 2019) - rwot9-prague/decentralized-did-rubric.md at master · WebOfTrustInfo/rwot9-prague | https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/decentralized-did-rubric.md | Paper | Main | 2019-09-06 | ||||||||||||||||||||||||||||
| 164 | DID Methods | IDCommons | https://iiw.idcommons.net/13D/_We_evaluated_7_DID_methods_with_the_W3C_DID_Rubric!_did:btcr,_did:sov,_did:ion,_did:web,_did:key,_did:peer,_did:ethr | Decentralized Identifiers | IIW | DID Method Rubric v1.0 | This rubric presents a set of criteria which an Evaluator can apply to any DID Method based on the use cases most relevant to them. We avoid reducing the Evaluation to a single number because the criteria tend to be multidimensional and many of the possible responses are not necessarily good or bad. It is up to the Evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs. | https://w3c.github.io/did-rubric/ | Guidance | Draft | Main | 2022-01-11 | ||||||||||||||||||||||||||||
| 165 | DID Methods | IDCommons | https://iiw.idcommons.net/13D/_We_evaluated_7_DID_methods_with_the_W3C_DID_Rubric!_did:btcr,_did:sov,_did:ion,_did:web,_did:key,_did:peer,_did:ethr | Walid Fdhila, Markus Sabadello | did:btcr, did:sov, did:ion, did:web, did:key, did:peer, did:ethr, Decentralized Identifiers | IIW | DID Methods Evaluation Report | This report evaluates a selection of DiD methods using the guidelines specified in the W3C DiD method Rubric V1.0 (draft 06 January 2021). The evaluation reflects the authors’ opinion based on documents and source code that are publicly available. The report mainly includes a comprehensive evaluation. | Web word processing, spreadsheets and presentations | https://docs.google.com/document/d/1jP-76ul0FZ3H8dChqT2hMtlzvL6B3famQbseZQ0AGS8// | Report | Main | 2021-04-04 | |||||||||||||||||||||||||||
| 166 | DID Methods | IDCommons | https://iiw.idcommons.net/13D/_We_evaluated_7_DID_methods_with_the_W3C_DID_Rubric!_did:btcr,_did:sov,_did:ion,_did:web,_did:key,_did:peer,_did:ethr | Walid Fdhila, Markus Sabadello | Decentralized Identifiers | IIW | Critera for DID Method Evaluation | The criteria selected for did evaluation are derived from (i) did rubric and (ii) principles of SSI.<br>(i) https://w3c.github.io/did-rubric/<br>(ii) https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md | https://docs.google.com/document/d/1vAKtMrsrjO_tLQhah8tRoLaIS7HpOIE6xM38ZoBpgWU/ | Guidance | Main | 2021-05 | ||||||||||||||||||||||||||||
| 167 | DID Methods | CCG Mailing List | Steve Capell | DID methods as W3C standards - a happy compromise? | can't we pick just a small number of un-controversial methods to standardise? even if it's just did:key and did:web to start with. | https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0117.html | Discussion | Discussion | Methods as Standards | 2022-02-22 | ||||||||||||||||||||||||||||||
| 168 | DID Methods | CCG Mailing List | Manu Sporny | Re: CCG Community opinions needed to define CCG scope (specifically re: did methods as work items) | Heather Vescent wrote:<br>1. What are the *pros* of including did methods as work items in the CCG?<br>Community vetting and approval of particular DID Methods.<br><br>Basically, broader and deeper review of DID Methods that we expect to be of great use to the world. I expect there will be DID Methods that the community wants to eventually propose as DID Methods for standardization (did:key and<br><br>did:web feel like two ones where we could get consensus on doing so). | https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0376.html | Discussion | Discussion | Methods as Standards | 2021-08-26 | ||||||||||||||||||||||||||||||
| 169 | DID Methods | ArcBlock | did:abt: | did:abt: | One of our main goal is to protect users’ privacy. So people do not use the DID generated from their master key to talk to DAPPs, instead, the WALLET automatically generates an extended DID according to the user’s master DID and the DAPP’s DID and use this extended DID to communicate with the DAPP. | ABT DID Protocol | https://arcblock.github.io/abt-did-spec/ | Specification | ABT Network | DID Methods | 2019-10-11 | https://github.com/arcblock/abt-did-spec/ | ||||||||||||||||||||||||||||
| 170 | DID Methods | CCG | did:btcr: | Christopher Allen, Ryan Grant, Kim Hamilton Duffy | did:btcr: | The Bitcoin Reference DID method (did:btcr) supports DIDs on the public Bitcoin blockchain. The Bitcoin Reference method has minimal design goals: a DID trust anchor based on the Bitcoin blockchain, updates publicly visible and auditable via Bitcoin transactions, and optionally, additional DID Document information referenced in the transaction OP_RETURN data field. No other Personal Identifiable Information (PII) would be placed on the immutable blockchain.<br>A secondary intent of the BTCR method is to serve as a very conservative, very secure example and some best practices for creating a DID method. The use cases for BTCR are focused on anonymous and pseudo-anonymous identities, web-of-trust style webs of identity, and absolute mimimal personal information disclosure. Other DID methods will likely need to loosen these standards.<br>Some aspects of the BTCR method will not be practical if inappropriately scaled — for instance, there is a transaction cost to update keys and DDO object, potential UTXO inflation (i.e. one additional unspent output for every BTCR-based identity), and even if segwit isn’t used it could cause blockchain bloat. However, identities using the BTCR method can be a strong as Bitcoin itself -- currently securing billions of dollars of digital value. | https://w3c-ccg.github.io/didm-btcr/ | https://w3c-ccg.github.io/didm-btcr/diagrams/btcr-tx-ref.png | Specification | Bitcoin | DID Methods | 2019-08-08 | ||||||||||||||||||||||||||||
| 171 | DID Methods | Blockstack | did:stack: | Jude Nelson | did:stack: | Blockstack's DID method is specified as part of its decentralized naming system. Each name in Blockstack has one or more corresponding DIDs, and each Blockstack DID corresponds to exactly one name -- even if the name was revoked by its owner, expired, or was re-registered to a different owner.<br>Blockstack is unique among decentralized identity systems in that it is not anchored to a specific blockchain or DLT implementation. The system is designed from the ground up to be portable, and has already been live-migrated from the Namecoin blockchain to the Bitcoin blockchain. The operational ethos of Blockstack is to leverage the must secure blockchain at all times -- that is, the one that is considered hardest to attack.<br>Blockstack's naming system and its DIDs transcend the underlying blockchain, and will continue to resolve to DID document objects (DDOs) even if the system migrates to a new blockchain in the future. | https://github.com/blockstack/blockstack-core/blob/stacks-1.0/docs/blockstack-did-spec.md | Specification | Bitcoin, Namecoin, Portable | DID Methods | 2019-07-19 | |||||||||||||||||||||||||||||
| 172 | DID Methods | WebofTrustInfo | did:erc725: | Markus Sabadello, Fabian Vogelsteller, Peter Kolarov | rwot06 | did:erc725: | Decentralized Identifiers (DIDs, see [1]) are designed to be compatible with any distributed ledger or network (called the target system). In the Ethereum community, a pattern known as ERC725 (see [2]) utilizes smart contracts for standard key management functions. We propose a new DID method that allows ERC725 identities to be treated as valid DIDs. One advantage of this DID method over others appears to be the ability to use the full flexibility of Ethereum smart contracts for key management purposes. | https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/DID-Method-erc725.md | Specification | Ethereum | DID Methods | ERC725 | 2018-02-21 | |||||||||||||||||||||||||||
| 173 | DID Methods | DIDWG | did:example: | did:example: | A DID is a simple text string consisting of three parts, the:<br>- URI scheme identifier (did)<br>- Identifier for the DID method<br>- DID method-specific identifier.<br>**EXAMPLE 1: A simple example of a decentralized identifier (DID)**<code>did:example:123456789abcdefghi</code><br>The example DID above resolves to a DID document. A DID document contains information associated with the DID, such as ways to cryptographically authenticate the DID controller, as well as services that can be used to interact with the DID subject. | https://w3c.github.io/did-core/#a-simple-example | https://w3c.github.io/did-core/diagrams/did_detailed_architecture_overview.svg | Specification | Portable | DID Methods | Credentials Community Group | 2022-07-19 | ||||||||||||||||||||||||||||
| 174 | DID Methods | TranSendX | did:ipid: | did:ipid: | The Interplanetary Identifiers DID method (did:ipid:) supports DIDs on the public and private Interplanetary File System (IPFS) networks. IPFS is the distributed content addressable permanent web. More specifically, the IPID DID method utilizes the Interplanetary Linked Data (IPLD) suite of tools. The IPID DID method has minimal design goals: a DID trust anchor based on the IPFS and Libp2p protocol. In and of itself, this is not a blockchain solution. However, blockchains and other distributed ledger technologies could be utilized to anchor the artifacts of this DID methods for further enhanced security. | https://did-ipid.github.io/ipid-did-method/ | Specification | IPFS | DID Methods | 2018-12-31 | ||||||||||||||||||||||||||||||
| 175 | DID Methods | lifeID Foundation | did:life: | lifeID | did:life: | lifeID is a decentralized, blockchain-based protocol that acts as an open identity provider. The protocol enables the creation and use of self-sovereign identities as well as the issuance of verifiable credentials to those identities. The blockchain-based components of the protocol include smart contracts for storage, revocation, and recovery of keys and credentials. These contracts may be run on any open, permissionless blockchain. The purpose of this protocol is to allow users to transact their identity in a way that minimizes data disclosure, is cryptographically secure, and enables censorship-resistant decentralized identity provisioning and recovery. The purpose of this specification is to describe how lifeID DIDs are created and the technical requirements to operate on the lifeID platform. | https://lifeid.github.io/did-method-spec/ | Specification | RChain | DID Methods | 2019-08-13 | |||||||||||||||||||||||||||||
| 176 | DID Methods | Sovrin Foundation | did:sov: | Mike Lodder | did:sov: | Sovrin is a public ledger designed specifically and only for privacy-preserving self-sovereign identity. The Sovrin Ledger is governed by the international non-profit Sovrin Foundation. As the only public ledger designed exclusively for self-sovereign identity, Sovrin is optimized for DIDs and DID Documents. DIDs are created, stored, and used with verifiable claims. This specification covers how these DIDs are managed. It also describes related features of Sovrin of particular interest to DID owners, guardians, and developers. | https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html | Specification | Sovrin | DID Methods | 2023-04-19 | |||||||||||||||||||||||||||||
| 177 | DID Methods | uPort | did:ethr: | did:ethr: | ETHR DID Method Specification<br><br>In the Ethereum community, a pattern known as ERC1056 (see [2]) utilizes a smart contract for a lightweight identity management system intended explicitly for off-chain usage.<br><br>The described DID method allows any Ethereum smart contract or key pair account, or any secp256k1 public key to become a valid identifier. Such an identifier needs no registration. In case that key management or additional attributes such as "service endpoints" are required, they are resolved using ERC1056 smart contracts deployed on the networks listed in the registry repository.<br><br>Mainnet • Ropsten • Rinkeby • Goerli • Kovan • RSK • Alastria • Telsius • ARTIS tau1 • ARTIS sigma1<br><br>Since each Ethereum transaction must be funded, there is a growing trend of on-chain transactions that are authenticated via an externally created signature and not by the actual transaction originator. This allows for 3rd party funding services, or for receivers to pay without any fundamental changes to the underlying Ethereum architecture. These kinds of transactions have to be signed by an actual key pair and thus cannot be used to represent smart contract based Ethereum accounts. ERC1056 proposes a way of a smart contract or regular key pair delegating signing for various purposes to externally managed key pairs. This allows a smart contract to be represented, both on-chain as well as off-chain or in payment channels through temporary or permanent delegates. | https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md | Specification | Ethereum | DID Methods | ERC1056, secp256k1 | 2022-11-07 | |||||||||||||||||||||||||||||
| 178 | DID Methods | DIF | DID resolver for Ethereum Addresses with support for key management (and DID reference implementation) | This library is intended to use ethereum addresses or secp256k1 publicKeys as fully self-managed Decentralized Identifiers and wrap them in a DID Document | https://github.com/decentralized-identity/ethr-did-resolver | Code | Ethereum | DID Methods | did:ethr:, secp256k1 | |||||||||||||||||||||||||||||||
| 179 | DID Methods | Digital Bazaar | did:v1: | did:v1: | There are two primary classes of DID-based identifiers in Veres One. The first type of identifier is called a cryptonym-based identifier. This identifier is a SHA-256 hash of a public key. Cryptonym-based identifiers are not required to be registered on the ledger and may be used as unregistered pseudonymous pairwise identifiers. These identifiers may also be registered on the ledger and MUST contain a authentication key with a public key fingerprint equal to the value of the cryptonym-based identifier.<code>did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ</code>The second type of identifier on Veres One is a UUID-based identifier and may be used by entities that want to store metadata on the ledger. These sorts of identifiers are often used, but not limited to, storing and refering to Capabilities and Revocation lists.<code>did:v1:uuid:804c6ac3-ce3b-46ce-b134-17175d5bee74</code> | https://w3c-ccg.github.io/did-method-v1/ | https://w3c-ccg.github.io/did-method-v1/diagrams/data-model.svg | Specification | Veres One | DID Methods | SHA-256 | 2019-11-22 | ||||||||||||||||||||||||||||
| 180 | DID Methods | Veres One | Joe Andrieu | did:v1: | Veres One (did:v1) Rubric Evaluation | Veres One, DID Rubric Evaluation, DID methods, DIDs, | https://iiw.idcommons.net/12B/_Veres_One_(did:v1)_Rubric_Evaluation | Session Notes | Veres One | DID Methods | 2021-05-06 | |||||||||||||||||||||||||||||
| 181 | DID Methods | Commercio Consortium | did:com: | did:com: | Commercio.network is a cosmos based sovereign blockchain network, built on the base of cosmos sdk and tendermint state machine replication engine, adopting Proof of Stake as a consensus algorithm.<br>Commercio.network, aims to be known as "The Documents Blockchain" and is to become "the easiest way for companies to manage their business documents using the blockchain technology".<br>Commercio.newtork ultimate goal is not just to share documents, but to create a network of trusted organizations, on the base of a web of trust, build on the Decentralized Identifier and Verifiable Credentials standard pillars. | https://github.com/commercionetwork/Commercio.network-DID-Method-Specification/ | Specification | commercio.network | DID Methods | Cosmos | Business Documents | 2019-11-12 | ||||||||||||||||||||||||||||
| 182 | DID Methods | Ontology Foundation | did:ont: | did:ont: | This specification defines how Ontology blockchain[1] stores DIDs and DID documents, and how to do CRUD operations on DID documents. More importantly, this specification confirms to the requirements specified in the DID specification[2] currently published by the W3C Credentials Community Group. | https://github.com/ontio/ontology-DID/blob/master/docs/en/DID-ONT-method.md | Specification | Ontology | DID Methods | 2018-08-11 | ||||||||||||||||||||||||||||||
| 183 | DID Methods | Vivvo Application Studios | did:vvo: | did:vvo: | Vivvo is a private ledger designed specifically and only for privacy-preserving self-sovereign identity. The Vivvo Ledger is governed by Vivvo Application Studios. As a private ledger designed exclusively for self-sovereign identity, Vivvo is optimized for DIDs and DID Documents. DIDs are created, stored, and used with verifiable claims. This specification covers how these DIDs are managed. It also describes related features of Vivvo of particular interest to DID owners, guardians, and developers. | https://vivvo.github.io/vivvo-did-scheme/spec/did-method-spec-template.html | Specification | Vivvo | DID Methods | 2020-12-18 | ||||||||||||||||||||||||||||||
| 184 | DID Methods | Aergo | did:aergo: | https://www.blocko.io/ | did:aergo: | The described DID method allows any Aergo smart contract or key pair account to become a valid identity. An identity needs no registration. In the case that key management or additional attributes such as "service endpoints" are required, we deployed did registry smart contracts [...] Since each Aergo transaction must be funded, in order to update attributes, account balance must be greater than zero. | https://www.aergo.io/ | Specification | Aergo | DID Methods | ||||||||||||||||||||||||||||||
| 185 | DID Methods | ICONLOOP | did:icon: | did:icon: | ICON[1,2,3] is a decentralized network that connects various independent communities to enable interoperability between them. ICON DID is a decentralized identifier devised to provide a way to uniquely identify a person, an organization, or a digital device across the communities connected to the ICON network. ICON DID method specification conforms to the DID and the DID Documents Spec[4]. This document describes how ICON blockchain manages the DIDs and the DID documents, and specifies a set of rules for how a DID is created, queried, updated, and revoked. | https://github.com/icon-project/icon-DID/blob/master/docs/ICON-DID-method.md | Specification | ICON | DID Methods | 2019-08-14 | ||||||||||||||||||||||||||||||
| 186 | DID Methods | Blockcore | did:is: | did:is: | This specification describes how the Blockcore Identity framework aligns with the DID specification and how the Blockcore Universal Resolver works.[...]The Blockcore Identity registry is a permissionless and borderless runtime for identities. | https://github.com/block-core/blockcore-did-method | Specification | Blockcore | DID Methods | 2020-08-31 | ||||||||||||||||||||||||||||||
| 187 | DID Methods | Raonsecure | did:iwt: | Verifiable Credentials | did:iwt: | InfoWallet is a decentralized network system for Self-Sovereign identity and Verifiable Claims. It can replace a legacy centralized credential system that with trusted blockchain node. In the InfoWallet system, several types of certificates are issued. DID(Decentralized Identifiers) is used as the unique identifier of the certificate. Also DID allows to obtain public key information for secure exchange of information between users. | https://github.com/infowallet/did_method/blob/master/did_method.md | Specification | InfoWallet | DID Methods | 2019-02-18 | |||||||||||||||||||||||||||||
| 188 | DID Methods | Ockam | did:ockam: | did:ockam: | A DID that uses this method MUST begin with the following prefix: did:ockam:. Per the DID specification, this prefix MUST be in lowercase. The format of remainder of the DID, after this prefix, is specified below in the section on Method Specific Identifiers. | https://github.com/ockam-network/did-method-spec/blob/master/README.md | Specification | Ockam | DID Methods | 2018-11-18 | ||||||||||||||||||||||||||||||
| 189 | DID Methods | Alastria National Blockchain Ecosystem | did:ala: | did:ala: | This document is divided into two parts:<br>- The first one defines the Alastria DID Method Specification, describing the Alastria DID Scheme and the Alastria DID Document.<br>- The second part describes the format for Alastria Credentials and Presentations in the current Alastria Red T, based on Quorum.<br>- The third part describes the Credentials and Presentation Life Cycle and the Private Credential Multi Hashes (PSM Hashes) used to anchor Credential and Presentation actions ensuring privacy. | https://github.com/alastria/alastria-identity/wiki/Alastria-DID-Method-Specification-(Quorum-version) | Specification | Alastria | DID Methods | Quorum | 2022-02-22 | |||||||||||||||||||||||||||||
| 190 | DID Methods | Ocean Protocol | did:op: | did:op: | **Requirements are:**<br>- The DID resolving capabilities MUST be exposed in the client libraries, enabling to resolve a DDO directly in a totally transparent way<br>- ASSETS are DATA objects describing RESOURCES under control of a PUBLISHER<br>- KEEPER stores on-chain only the essential information about ASSETS<br>- PROVIDERS store the ASSET metadata off-chain<br>- KEEPER doesn't store any ASSET metadata<br>- OCEAN doesn't store ASSET contents (e.g. files)<br>- An ASSET is modeled in OCEAN as on-chain information stored in the KEEPER and metadata stored in OCEANDB<br>- ASSETS on-chain information only can be modified by OWNERS or DELEGATED USERS<br>- ASSETS can be resolved using a Decentralized ID (DID) included on-chain and off-chain<br>- A DID Document (DDO) should include the ASSET metadata<br>- Any kind of object registered in Ocean SHOULD have a DID allowing one to uniquely identify that object in the system<br>- ASSET DDO (and the metadata included as part of the DDO) is associated to the ASSET information stored on-chain using a common DID<br>- A DID can be resolved to get access to a DDO<br>- ASSET DDOs can be updated without updating the on-chain information<br>- ASSET information stored in the KEEPER will include a checksum attribute<br>- The ASSET on-chain checksum attribute SHOULD include a one-way HASH calculated using the DDO content<br>- After the DDO resolving, the DDO HASH can be calculated off-chain to validate if the on-chain and off-chain information is aligned<br>- A HASH not matching with the checksum on-chain means the DDO was modified without the on-chain update<br>- The function to calculate the HASH MUST BE standard | https://web.archive.org/web/20210428122924/https://github.com/oceanprotocol/OEPs/blob/master/7/v0.2/README.md | Specification | Ocean Protocol | DID Methods | 2021-04-28 | ||||||||||||||||||||||||||||||
| 191 | DID Methods | JLinc.org | did:jlinc: | Victor Grey | did:jlinc: | JLINC is a protocol for sharing data protected by an agreement on the terms under which the data is being shared.<br><br>This document specifies methods for creating and editing Decentralized IDs (DIDs) suitable for use with the [JLINC protocol](https://protocol.jlinc.org/). | https://did-spec.jlinc.org/ | Specification | JLINC Protocol | DID Methods | 2018-10-13 | |||||||||||||||||||||||||||||
| 192 | DID Methods | DIF | did:ion: | did:ion: | ION is a public, permissionless, Decentralized Identifier (DID) network that implements the blockchain-agnostic Sidetree protocol on top of Bitcoin (as a 'Layer 2' overlay) to support DIDs/DPKI (Decentralized Public Key Infrastructure) at scale.<br><br>IMPORTANT NOTE: The majority of ION's code is developed under the blockchain-agnostic Sidetree protocol's repo: [https://github.com/decentralized-identity/sidetree](https://github.com/decentralized-identity/sidetree), which this project uses internally with the code required to run the protocol on Bitcoin, as the ION network.<br><br>**Key Points:**<br>- ION is public and permissionless - the system is decentralized, no company, organization, or group owns/controls the identifiers and DPKI entries in the system, and no one dictates who can participate.<br>- ION doesn't introduce new tokens/coins - Bitcoin is the only unit of value relevant in the operation of the on-chain aspects of the ION network.<br>- ION is not a sidechain or consensus system - the network nodes do not require any additional consensus mechanism. | The Identity Overlay Network (ION) is a DID Method implementation using the Sidetree protocol atop Bitcoin - GitHub - decentralized-identity/ion: The Identity Overlay Network (ION) is a DID Method implementation using the Sidetree protocol atop Bitcoin | https://github.com/decentralized-identity/ion-did-method | Specification | Bitcoin | DID Methods | 2023-04-20 | |||||||||||||||||||||||||||||
| 193 | DID Methods | Jolocom | did:jolo: | did:jolo: | It’s core technologies are the Ethereum blockchain and the Interplanetary File System (IPFS). The Jolocom DID method uses IPFS as a decentralised CAS layer for DID Documents. A deployed smart contract provides a mapping from a DID to an IPFS hash address of the corrosponding DID Document. This enables DID Documents on IPFS to be effectively addressed via their DIDs. | https://github.com/jolocom/jolo-did-method/blob/master/jolocom-did-method-specification.md | Specification | Ethereum | DID Methods | ION, Sidetree | 2020-08-16 | |||||||||||||||||||||||||||||
| 194 | DID Methods | Bryk | did:bryk: | Marcos Allende, Sandra Murcia, Flavia Munhoso, Ruben Cessa | did:bryk: | The method specification provides all the technical considerations, guidelines and recommendations produced for the design and deployment of the DID method implementation. The document is organized in 3 main sections.<br><br>- DID Schema. Definitions and conventions used to generate valid identifier instances.<br>- DID Document. Considerations on how to generate and use the DID document associated with a given identifier instance.<br>- Agent Protocol. Technical specifications detailing how to perform basic network operations, and the risk mitigation mechanisms in place, for tasks such as:<br>- Publish a new identifier instance.<br>- Update an existing identifier instance.<br>- Resolve an existing identifier and retrieve the latest published version of its DID Document. | Reference implementation for the 'bryk' DID method. - did-method/README.md at master · aidtechnology/did-method | https://github.com/bryk-io/did-method/blob/master/README.md | Specification | bryk | DID Methods | IPFS | 2021-12-27 | |||||||||||||||||||||||||||
| 195 | DID Methods | Daniel Hardman | did:peer: | did:peer: | Most documentation about decentralized identifiers (DIDs) describes them as identifiers that are rooted in a public source of truth like a blockchain, a database, a distributed filesystem, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases. | https://identity.foundation/peer-did-method-spec/ | Specification | P2P | DID Methods | 2022-10-13 | ||||||||||||||||||||||||||||||
| 196 | DID Methods | Affinidi | did:peer: | Peer DIDs — An Off-Ledger DID Implementation | - No transaction costs involved<br>- Easy to create and maintain<br>- Since these DIDs are independent of a central system such as a GDPR controller, they can be scaled as needed<br>- Offers the highest levels of privacy as only the parties involved can access the DIDs<br>- No uncertainties or external problems since these DIDs are not associated with any particular network<br>- No degradation of trust throughout the entire lifecycle.<br>- In tune with local-first software philosophies<br>- Reduces unnecessary correlation between a verifier and an issuer of a [verifiable credential](https://academy.affinidi.com/what-are-verifiable-credentials-79f1846a7b9). | Peer DIDs ensure a cheap, secure, and scalable way to maintain interaction between two entities in SSI implementations through verifiable credentials. | https://academy.affinidi.com/peer-dids-an-off-ledger-did-implementation-5cb6ee6eb168 | page | P2P | DID Methods | 2021-05-18 | |||||||||||||||||||||||||||||
| 197 | DID Methods | SelfKey | did:selfkey: | did:selfkey: | The following document defines a DID method for the SelfKey Identity platform. Although this method provides support to the SelfKey ecosystem and its related applications, the underlying DID platform is fully decentralized, and it's designed to serve as a DID layer for other systems that might find it valuable.<br><br>The following specifications are subject to change in the future, yet they MUST comply with the latest version of the [generic DID specs](https://w3c-ccg.github.io/did-spec/) as specified by the W3C Credentials Community Group.<br><br>The functionality for this method is provided by the DIDLedger smart contract found in [this repository](https://github.com/SelfKeyFoundation/selfkey-identity). | https://github.com/SelfKeyFoundation/selfkey-identity/blob/develop/DIDMethodSpecs.md | Specification | Ethereum | DID Methods | 2019-04-10 | ||||||||||||||||||||||||||||||
| 198 | DID Methods | Metadium | did:meta: | did:meta: | Metadium is the next-generation identity system powered by blockchain technology. Metadium Decentralized Identifiers is a distributed identifier designed to provide a way for a community connected to the Metadium Ecosystem to uniquely identify an individual, organization, or digital device. The role of a Metadium DID is to provide a service that supports user-authentication and personal information verification | https://github.com/METADIUM/meta-DID/blob/master/doc/DID-method-metadium.md | Specification | Metadium | DID Methods | 2021-06-02 | ||||||||||||||||||||||||||||||
| 199 | DID Methods | Chainyard | did:tys: | did:tys: | The TYS network is a cross industry source of supplier information and identity helping to simplify and accelerate the onboarding and lifecycle management process. TYS is a fit-for-purpose blockchain optimized for sharing supplier credentials in a supply chain environment. TYS DIDs may be used by Suppliers, Buyers, Verifiers, Banks and other organizations to establish identities for verifiable claims made by any party.<br><br>TYS is implemented on Hyperledger Fabric, a permissioned blockchain technology under the Linux Foundation’s Hyperledger Project. The “Smart Contract” Functions are written in “Golang” and all client APIs are provided as REST APIs written in “Javascript” running on “NodeJS. | https://github.com/chainyard-tys/tys/blob/master/README.md | Specification | TYS Network | DID Methods | Lifecycle Managment | 2019-04-23 | |||||||||||||||||||||||||||||
| 200 | DID Methods | Personal | did:git: | Dave Huseby | Internet Identity Workshop | did:git: | The Git revision control tool is designed to function in a decentralized peer-to-peer fashion to facilitate collaboration in the frequently-disconnected world. Git uses a directed acyclic graph (DAG) of commits that represent the changes to the folders and files in the repository. Because it uses blockchain-like hash-linking of commits, Git is effectively a blockchain and distributed ledger with the patch review and merge process functioning as the consensus mechanism. This makes it a great tool for tracking the provenance of data inside the repository. Git also records the author and other meta data such as digital signatures with each commit linking identity of committers to each commit. Git repos therefore contain all of the information needed to serve as the single source of truth for the provenance of the data it contains and the identities of the contributors that created it. | https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md | Specification | depreciated | Git | DID Methods | DAG | 2019-06-06 | ||||||||||||||||||||||||||
| 201 | DID Methods | cryptidtech | https://iiw.idcommons.net/12A/_Git_as_Authentic_Data_Creation_Tool_(a.k.a._what_happened_to_did:git%3F_a.k.a._independently_verifiable,_secure,_developer_sovereign,_open_source_software_supply_chain) | Dave Huseby | Git Cryptography Protocol | This specification documents a new, proposed protocol Git uses when interacting with cryptographic signing and verification tools. The goal of this modification is to make Git able to use any signing and verification tools. The design eliminates all of the tool-specific code in Git, easing maintenance and increasing flexibility. The protocol takes is inspired by the Assuan Protocol used by GPG to link its component executables together but uses Git's pkt-line framing. | https://github.com/cryptidtech/git-cryptography-protocol/blob/main/Git%20Cryptography%20Protocol.md | Specification | Git | DID Methods | Software Development | 2021-08-14 | ||||||||||||||||||||||||||||
| 202 | DID Methods | BiiLabs | did:tangle: | did:tangle: | IOTA is a public distributed ledger that utilizes an invention called the Tangle at its core, address scalability issues and having no transaction fee, that encourages adoption of the technology in the industry. TangleID is intended to implement DIDs and DID Documents. | https://github.com/TangleID/TangleID/blob/develop/did-method-spec.md | Specification | IOTA Tangle | DID Methods | 2022-06-06 | ||||||||||||||||||||||||||||||
| 203 | DID Methods | Halialabs | did:emtrust: | did:emtrust: | The Emtrust DID method utilizes Hyperledger fabric as the DLT implementation, having an identity channel which is shared among the identity nodes with participating organizations. The DID document along with metadata of third party endorsements resides on ledger and the private information of users are kept on the mobile or persona devices which never leaves the device. The Interaction of DID and blockchain ledger happens via the API servers hosted by any participating organizations. | https://github.com/Halialabs/did-spec/blob/gh-pages/readme.md | Specification | Hyperledger Fabric | DID Methods | 2019-06-17 | ||||||||||||||||||||||||||||||
| 204 | DID Methods | Token.TM | did:ttm: | did:ttm: | <32 byte hexadecimal stringcorresponds to keccak256 and the hash value of Ethereum address connected by random numbers generated in the DID contract.<br><br>DID is registered in the contract and controlled by a single Ethereum address, which is set by default to the address where the createDID method was originally called. Then, this address can transfer control to a different address, or update/delete the corresponding DID in the contract. | https://github.com/TokenTM/TM-DID/blob/master/docs/en/DID_spec.md | Specification | TMChain | DID Methods | 2019-07-11 | ||||||||||||||||||||||||||||||
| 205 | DID Methods | Weelink | did:wlk: | did:wlk: | Weelink DID is a new blockchain-based authentication method that follows all the requirements of W3C. Based on Weelink Wallet, our method provides a series of APIs and services for a fast and secure authentication process. | https://weelink-team.github.io/weelink/DIDDesignEn | Specification | Weelink Network | DID Methods | 2019-07-19 | ||||||||||||||||||||||||||||||
| 206 | DID Methods | Pistis | did:pistis | Andrea Taglia, Matteo Sinico | did:pistis | This specification defines how Pistis deals with DID and DID Documents and how it interacts with the Ethereum blockchain. Also CRUD operations on DID documents are described. This specification confirms to the requirements specified in the DID specification[1] currently published by the W3C Credentials Community Group.<br><br>Pistis is a credential management system based on the Ethereum blockchain. It provides a set of novel smart contracts to handle efficient multi signature operations, delegates management, permissioned access to extensible services based upon the Decentralized IDentifier specification. | https://github.com/uino95/ssi/blob/consensys/dashboard/server/pistis/pistis-did-resolver/README.md | Specification | Ethereum | DID Methods | 2019-08-29 | |||||||||||||||||||||||||||||
| 207 | DID Methods | Holo.Host | did:holo: | did:holo: | Decentralized Identifiers (DIDs, see [1]) are designed to be compatible with any distributed ledger or network (called the target system). We will be specing and prototyping a DID method for holochain. | https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did:hc-method.md | Specification | Holochain | DID Methods | 2019-09-08 | ||||||||||||||||||||||||||||||
| 208 | DID Methods | CCG | did:web: | Oliver Terbu, Mike Xu, Dmitri Zagidulin, Amy Guy | did:web: | The target system of the Web DID method is the web host that the domain name described by the DID resolves to when queried through the Domain Name System (DNS).<br><br>The method specific identifier MUST match the common name used in the SSL/TLS certificate, and it MUST NOT include IP addresses or port numbers. Directories and subdirectories MAY optionally be included, delimited by colons rather than slashes.<code>did:web:w3c-ccg.github.io:user:alice</code> | https://github.com/w3c-ccg/did-method-web | Specification | Web | DID Methods | 2023-05-06 | |||||||||||||||||||||||||||||
| 209 | DID Methods | IoTeX Foundation | did:io: | did:io: | Our DID design allows each manufacture or entity to have its own namespace, which stores and manages DIDs through a self-managed DID contract. A self-managed contract could have customized business logic to adapt the application's needs but has to implement the SelfManagedDID interface | https://github.com/iotexproject/iotex-did/blob/master/README.md | Specification | IoTeX | DID Methods | 2021-07-28 | ||||||||||||||||||||||||||||||
| 210 | DID Methods | Vaultie Inc. | did:vaultie: | did:vaultie: | Vaultie DID method uses IPFS as a decentralised storage for DID Documents. An Ethereum transaction, that does not require any additional Smart Contracts, provides a mapping from a DID to an IPFS hash address of the corrosponding DID Document. This enables DID Documents on IPFS to be effectively addressed via their DIDs. While this method requires additional step in order to lookup DID Document, the method is much more cost effective than using Smart Contracts and Ethereum's expensive storage. | https://github.com/vaultie/vaultie-did-method/blob/master/vaultie-did-method-specification.md | Specification | Ethereum | DID Methods | 2020-08-19 | ||||||||||||||||||||||||||||||
| 211 | DID Methods | MOAC Blockchain Tech, Inc. | did:moac: | David Ricardo Wilde | did:moac: | The MOAC DID method uses MOAC blockchain as a decentralized storage layer for DID Documents. A deployed smart-contract provides a mapping from a DID to an MOAC blockchain hash address of the corrosponding DID Document. This enables DID Documents on MOAC blockchain to be effectively addressed via their DIDs. | https://github.com/DavidRicardoWilde/moac-did/blob/master/did-moac-method.md | Specification | MOAC | DID Methods | 2019-10-03 | |||||||||||||||||||||||||||||
| 212 | DID Methods | OmniOne | did:omn: | did:omn: | OmniOne is a decentralized network system for Self-Sovereign identity and Verifiable Claims. It can replace a legacy centralized credential system that with trusted blockchain node. In the OmniOne system, several types of certificates are issued. DID(Decentralized Identifiers) is used as the unique identifier of the certificate. Also DID allows to obtain public key information for secure exchange of information between users. | https://github.com/OmniOneID/did_method/blob/master/did_method.md | Specification | OmniOne | DID Methods | 2019-05-30 | ||||||||||||||||||||||||||||||
| 213 | DID Methods | Workday, Inc. | did:work: | did:work: | Workday offers a decentralized Credentialing Platform with a Blockchain based trust layer. A key component of the platform is the WayTo by Workday mobile app which allows the user to store verifiable identity documents, encrypted using their own personal encryption key, which is managed in the Trusted Execution Environment (TEE) of their mobile device. The mobile app can hold official documents, training certifications, verified accomplishments and other credentials. The user can choose what to share, and with whom to share it with. Users of the Workday Credentialing Platform will have a DID and a corresponding DID Document on a permissioned ledger, which credential verifiers can use to validate users’ cryptographic signatures, included in their credentials. | https://workday.github.io/work-did-method-spec/ | data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyRpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNiAoTWFjaW50b3NoKSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpFMTZCRDY3REIzRjAxMUUyQUQzREIxQzRENUFFNUM5NiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpFMTZCRDY3RUIzRjAxMUUyQUQzREIxQzRENUFFNUM5NiI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOkUxNkJENjdCQjNGMDExRTJBRDNEQjFDNEQ1QUU1Qzk2IiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOkUxNkJENjdDQjNGMDExRTJBRDNEQjFDNEQ1QUU1Qzk2Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+SM9MCAAAA+5JREFUeNrEV11Ik1EY3s4+ddOp29Q5b0opCgKFsoKoi5Kg6CIhuwi6zLJLoYLopq4qsKKgi4i6CYIoU/q5iDAKs6syoS76IRWtyJ+p7cdt7sf1PGOD+e0c3dygAx/67ZzzPM95/877GYdHRg3ZjMXFxepQKNS6sLCwJxqNNuFpiMfjVs4ZjUa/pmmjeD6VlJS8NpvNT4QQ7mxwjSsJiEQim/1+/9lgMHgIr5ohuxG1WCw9Vqv1clFR0dCqBODElV6v90ogEDjGdYbVjXhpaendioqK07CIR7ZAqE49PT09BPL2PMgTByQGsYiZlQD4uMXtdr+JxWINhgINYhGT2MsKgMrm2dnZXgRXhaHAg5jEJodUAHxux4LudHJE9RdEdA+i3Juz7bGHe4mhE9FNrgwBCLirMFV9Okh5eflFh8PR5nK5nDabrR2BNJlKO0T35+Li4n4+/J+/JQCxhmu5h3uJoXNHPbmWZAHMshWB8l5/ipqammaAf0zPDDx1ONV3vurdidqwAQL+pEc8sLcAe1CCvQ3YHxIW8Pl85xSWNC1hADDIv0rIE/o4J0k3kww4xSlwIhcq3EFFOm7KN/hUGOQkt0CFa5WpNJlMvxBEz/IVQAxg/ZRZl9wiHA63yDYieM7DnLP5CiAGsC7I5sgtYKJGWe2A8seFqgFJrJjEPY1Cn3pJ8/9W1e5VWsFDTEmFrBcoDhZJEQkXuhICMyKpjhahqN21hRYATKfUOlDmkygrR4o4C0VOLGJKrOITKB4jijzdXygBKixyC5TDQdnk/Pz8qRw6oOWGlsTKGOQW6OH6FBWsyePxdOXLTgxiyebILZCjz+GLgMIKnXNzc49YMlcRdHXcSwxFVgTInQhC9G33UhNoJLuqq6t345p9y3eUy8OTk5PjAHuI9uo4b07FBaOhsu0A4Unc+T1TU1Nj3KsSSE5yJ65jqF2DDd8QqWYmAZrIM2VlZTdnZmb6AbpdV9V6ec9znf5Q7HjYumdRE0JOp3MjitO4SFa+cZz8Umqe3TCbSLvdfkR/kWDdNQl5InuTcysOcpFT35ZrbBxx4p3JAHlZVVW1D/634VRt+FvLBgK/v5LV9WS+10xMTEwtRw7XvqOL+e2Q8V3AYIOIAXQ26/heWVnZCVfcyKHg2CBgTpmPmjYM8l24GyaUHyaIh7XwfR9ErE8qHoDfn2LTNAVC0HX6MFcBIP8Bi+6F6cdW/DICkANRfx99fEYFQ7Nph5i/uQiA214gno7K+guhaiKg9gC62+M8eR7XsBsYJ4ilam60Fb7r7uAj8wFyuwM1oIOWgfmDy6RXEEQzJMPe23DXrVS7rtyD3Df8z/FPgAEAzWU5Ku59ZAUAAAAASUVORK5CYII= | Specification | dead | Hyperledger Fabric | DID Methods | 2020-06-25 | ||||||||||||||||||||||||||||
| 214 | DID Methods | VP Inc. | did:vid: | did:vid: | The system aims to provide secure authentication and various payment services based on the DID and Verifiable Claims specificiatons published by the W3C and the Decentralised Identity Foundation. VP DID is a decentralized identifier devised to provide a way to uniquely identify a person, an organization. VP DID document contains information for providing various payment methods among network participants in a decentralized way. This specification defines how VP blockchain stores DIDs and DID documents, and how to do CRUD operations on DID documents. | https://github.com/vpayment/did-method-spec/blob/master/vid.md | Specification | VP | DID Methods | 2019-10-15 | ||||||||||||||||||||||||||||||
| 215 | DID Methods | Baidu, Inc. | did:ccp: | did:ccp: | Application scenarios:<br>- Digital identity<br>- Joint member key customer system<br>- Financial KYC<br>- Exchange<br>- Smart City<br>- IoT deviceless identity management<br><br>Program features:<br>Building a decentralized ID system based on blockchain and consortium chains will have almost equal control over the system and enhance cooperation intentions.<br><br>Blockchain asymmetric encryption technology combines public and private keys to ensure the authenticity and reliability of ID and certification.<br><br>Form a richer user portrait, with multiple tags (VIP authentication, privilege authentication, asset authentication...) and one ID. | https://did.baidu.com/did-spec/ | https://did.baidu.com/images/did-login-pc.png | Specification | Quorum | DID Methods | 2016-02-08 | |||||||||||||||||||||||||||||
| 216 | DID Methods | Jnctn Limited | did:jnctn: | did:jnctn: | The system provides secure credential management services based on the DID and Verifiable Claims specifications published by the W3C and the Decentralised Identity Foundation. JNCTN DID method enables an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers with self soverign identity services. JNCTN DID document contains information for accessing JNCTN DID network methods, how JNCTN stores DIDs and DID documents, and how to do CRUD operations on JNCTN DID documents. | https://github.com/jnctn/did-method-spec/ | Specification | dead | Jnctn Network | DID Methods | ||||||||||||||||||||||||||||||
| 217 | DID Methods | evan GmbH | did:evan: | did:evan: | evan.network is a blockchain for digitalization and automation of business transactions. The network members create digital twins for their machines and products and develop standards for cross-company transactions. The open technology allows integration into existing business models. evan.network guarantees 100% reliable and permanently secured information. | https://github.com/evannetwork/evan.network-DID-method-specification/blob/master/evan_did_method_spec.md | Specification | evan.network | DID Methods | 2020-03-24 | ||||||||||||||||||||||||||||||
| 218 | DID Methods | Elastos Foundation | did:elastos: | did:elastos: | DID is completely under the control of the DID subject, without reliance on any centralized registration body, commercial identity provider, or organization issuing certificates. The DID is described in the DID documents. Each DID document includes at least two items: encryption materials and verification methods. The encryption materials integrated with the verification methods provides a set of identify verification mechanisms (such as a public key, anonymous biological identification agreement, etc.), with other optional parts that can be used according to the needs of the application and of the user. | https://github.com/elastos/Elastos.DID.Method/blob/master/DID/Elastos-DID-Method-Specification_en.md | Specification | Elastos ID Sidechain | DID Methods | 2021-01-04 | ||||||||||||||||||||||||||||||
| 219 | DID Methods | BOTLabs GmbH | did:kilt: | did:kilt: | KILT DIDs are stored on KILT Protocol's blockchain that is public and by definition decentralized. The KILT Blockchain runs in a proof-of-authority manner and will become permissionless, see `§ Status of this document` in this specification document. | https://github.com/KILTprotocol/kilt-did-driver/blob/master/docs/did-spec/spec.md | Specification | KILT Blockchain | DID Methods | 2022-10-11 | ||||||||||||||||||||||||||||||
| 220 | DID Methods | Transmute | did:elem: | did:elem: | Element is an implementation of the Sidetree protocol that uses the Ethereum blockchain as the ledger layer and IPFS as the Content-addressable storage layer | https://github.com/decentralized-identity/element/blob/master/docs/did-method-spec/spec.md | Specification | DID Methods | Element DID | 2020-04-06 | ||||||||||||||||||||||||||||||
| 221 | DID Methods | Transmute | did:github: | did:github: | The `github` method is meant to make working with DIDs very simple at the cost of trusting Github.com for assisting in resolving DID Documents.<br><br>Many developers are familar with Github, and its 2 supported public key cryptosystems, GPG and SSH.<br><br>Linked Data Signatures are difficult to work with when operating a server or running a local node of some distributed system / blockchain is a requirement.<br><br>The objective of GitHub DID is to encourage contribution to the DID Spec and Linked Data Signatures, and allow rapid development of extensions to these without requiring the use of slow, or complicated more trustless infrastructure, such as blockchains or other distributed systems. | https://docs.github-did.com/did-method-spec/ | Specification | Github | DID Methods | 2020-05-08 | ||||||||||||||||||||||||||||||
| 222 | DID Methods | teleinfo caict | did:bid: | did:bid: | BID provides distributed identifiers and blockchain-based digital identity services for people, enterprises, devices and digital objects. It aims to build a decentralized, data-secure, privacy-protected and flexible identifier system that addresses trusted connections among people, enterprises, devices and digital objects，enabling the vision of the Internet of Things and trust ingress with everything. | https://github.com/teleinfo-bif/bid/tree/master/doc/en | Specification | bif | DID Methods | 2022-11-03 | ||||||||||||||||||||||||||||||
| 223 | DID Methods | PalletOne | did:ptn: | did:ptn: | Description of each field in the Base DID Document example (★ required fields, others are optional fields):<br><br>* ★ `context` A single value or an array, specifying the syntax standard that the DID Document format complies with.<br>* `controller` Single value or array, other owners of DID Document. You can specify other DIDs to manage the file, and the permissions of other DIDs will be set in the corresponding operations authentication, updation, deletion, and recovery later. The default is controlled by the DID in the DID Document corresponding to the Base DID Document.<br>* ★ `publicKey` A single value or an array that controls the public key information corresponding to the private key of the DID Document.<br>* ★ `id` The ID of the public key, `#keys-<num>` expressed in a unified way, incremented `<num>` from the `1` beginning.<br>* ★ `type` The algorithm of public key generation is unified with the chain,<br> * `controller` The owner of the public key `controller` corresponds to the one in the previous level. The format is `<DID>#keys-<num>`. The default situation is controlled by the document DID. `<DID>` The value on the stage controller, a `#keys-<num>` is `<DID>` a corresponding public key `id`.<br>* `publicKeyHex` Hexadecimal information of the public key. When the above controller is the default, this field is **required**.<br>* ★ `authentication` Specify `publicKey` which fields can be used for authentication.<br>* `updation` Specify `publicKey` which fields can be used for DID Document **update** operations, such as updating information such as pubkey or service.<br>* `deletion` Specify `publicKey` which fields can be used for DID Document **delete** operation.<br>* `recovery` Specify `publicKey` which fields can be used for DID Document **recovery** operations. | https://github.com/palletone/palletone-DID/blob/master/docs/did-method/README.md | Specification | PalletOne | DID Methods | 2020-02-29 | ||||||||||||||||||||||||||||||
| 224 | DID Methods | Echo Technological Solutions LLC | did:echo: | did:echo: | We propose a new DID method that allows special objects in ECHO network to be treated as valid DIDs. | https://github.com/echoprotocol/uni-resolver-driver-did-echo/blob/master/echo_did_specifications.md | Specification | Echo | DID Methods | 2022-10-11 | ||||||||||||||||||||||||||||||
| 225 | DID Methods | SecureKey | did:trustbloc: | did:trustbloc: | The did:trustbloc DID method allows groups of independent entities to share custody of a DID registry consisting of a Sidetree implementation over a permissioned ledger. For more information on Sidetree, please refer to the Sidetree protocol specification.<br><br>Independent stakeholders wishing to transact with one another using DIDs can come together to form a consortium to manage their shared custody of a ledger.<br><br>This spec defines a discovery service. The discovery service provided by the TrustBloc DID Method allows a client to verify that a consortium is endorsed by its constituent stakeholders, verify that the configuration files of each stakeholder (which includes a list of Sidetree endpoints) are signed by the respective stakeholders, and use the provided Sidetree endpoints to perform Sidetree DID operations. | https://github.com/trustbloc/trustbloc-did-method/blob/master/docs/spec/trustbloc-did-method.md | Specification | Hyperledger Fabric | DID Methods | 2020-04-09 | ||||||||||||||||||||||||||||||
| 226 | DID Methods | YLZ Inc. | did:san: | did:san: | The system aims to provide secure authentication and various health services based on the SAN blockchain and DID & Verifiable Credential Specifications published by the W3C. | https://github.com/Baasze/DID-method-specification | Specification | SAN Cloudchain | DID Methods | 2020-04-17 | ||||||||||||||||||||||||||||||
| 227 | DID Methods | Gataca | did:gatc: | did:gatc: | Gataca’s platform is based on a mobile identity portfolio, a set of APIs, and controllers for multiple blockchain networks.<br><br>Gataca is agnostic to the blockchain network. We adapt our infrastructure to the third party’s preferred ledger. Gataca currently supports the public network Ethereum and private networks based on Hyperledger Fabric, Hyperledger Besu or Quorum. Other networks may be added as requested.<br>This document provides the DID method specs for how our DID schema is implemented on the Ethereum network.<br><br>The simple structure links an object to a DID with states and public keys. Users do not need privileges to read the information on the blockchain but do need them to write. Gataca is the unique user that can modify the smart contract. | https://github.com/gatacaid/gataca-did-method | Specification | Ethereum, Hyperledger Fabric, Hyperledger Besu, Alastria | DID Methods | 2020-05-05 | ||||||||||||||||||||||||||||||
| 228 | DID Methods | Sphereon, Factomatic, Factom Inc | did:factom: | did:factom: | This proposal contains the interoperability specifications for products creating, reading (resolving) updating and deactivating Decentralized Identifiers on top of the Factom Protocol. This specification is not about other products wanting to use DIDs for their specific purpose, like signing or voting. This document describes the low level data structures and rules for DIDs, DID documents, resolution and registration on Factom itself. | https://github.com/factom-protocol/FIS/blob/master/FIS/DID.md | Specification | Factom | DID Methods | 2019-11-02 | ||||||||||||||||||||||||||||||
| 229 | DID Methods | Cryptonics Consulting | did:signor: | did:signor: | DIDs are registered in the DID Registry on-chain, and have a controller and a subject, expressed in the form of Ethereum addresses. The DID controller may or may not be the subject itself. Multiple controllers can be implemented through proxy smart contracts. | https://github.com/cryptonicsconsulting/signor-did-contracts/blob/master/did-method-spec.md | Specification | Ethereum, Hedera Hashgraph, Quorum, Hyperledger Besu | DID Methods | 2020-11-16 | ||||||||||||||||||||||||||||||
| 230 | DID Methods | Hedera Hashgraph, Swisscom Blockchain AG | did:hedera: | did:hedera: | This document defines a binding of the Decentralized Identifier architecture to Hedera Hashgraph - specifically how to use the Hedera File Service to record membership in 'business application networks' (appnets) and how to use the Hedera Consensus Service (HCS) for CRUD mechanisms on DID documents stored in such business application network. An business application network is a network of computers that store some set of business data (such as DID Documents) in a shared state, and rely on the Hedera mainnet for timestamping and ordering the transactions that cause that business application network state to change. An business application network could be exclusively dedicated to managing DID Documents and other identity artifacts in its state, or it could itself be multi-purpose. | https://github.com/hashgraph/did-method/blob/master/did-method-specification.md | Specification | Hedera Hashgraph | DID Methods | 2020-05-14 | ||||||||||||||||||||||||||||||
| 231 | DID Methods | ProximaX Enterprise, Proximax Inc. | did:sirius: | did:sirius: | The target system is the ProximaX Sirius Chain network. This can either be:<br>- Sirius Chain on Main Net<br>- Sirius Chain on Test Net<br>- Sirius Chain on Private Net | https://gitlab.com/proximax-enterprise/siriusid/sirius-id-specs/-/blob/master/docs/did-method-spec.md | Specification | ProximaX Sirius Chain | DID Methods | 2020-07-04 | ||||||||||||||||||||||||||||||
| 232 | DID Methods | Dock | did:dock: | did:dock: | Currently, three public key and signing algorithms are supported for authentication.<br>- Schnorr signatures with Sr25519. The public key is 32 bytes and signature is 64 bytes in size. These are supported by Substrate and Polkadot.<br>- EdDSA signatures with Ed25519 curve. The public key is 32 bytes and signature is 64 bytes in size.<br><br>Dock is currently running as a proof of authority network but will evolve into a proof of stake chain. DIDs can be created by anyone holding Dock tokens but the creator of the DID is not necessarily the owner of the DID and thus cannot manage (update, remove) them. DIDs are managed using their corresponding private keys and these keys are independent of keys controlling the Dock tokens spent while creating the DID.<br><br>The chain does not store the full DID document but only the DID, the corresponding keys and controllers and block number for the last update and this block number changes with each update to the DID. This is needed for replay protection. Dock's client SDK retrieves those details and constructs the full DID document. | https://github.com/docknetwork/dock-did-driver/blob/master/Dock%20DID%20method%20specification.md | Specification | Dock | DID Methods | 2022-07-21 | ||||||||||||||||||||||||||||||
| 233 | DID Methods | did-twit | did:twit: | did:twit: | Twitter is a highly used and influential social media network that lacks decentralization and higher levels of trust (i.e. signed messages). The `did:twit` specification makes an attempt to increase trust in Twitter interactions.<br><br>The method is similar to [did:key](https://w3c-ccg.github.io/did-method-key) in the sense that it is uses a `did` to wrap a single public key.<br><br>The objective of Twitter DID, similar to that of the [GitHub DID Method](https://github.com/decentralized-identity/github-did), is to encourage use of the [DID Spec](https://w3c-ccg.github.io/did-spec/), by lowering the barrier to entry for use of the technology, and promote higher trust interactions. | https://github.com/did-twit/did-twit/blob/master/spec/index.md | Specification | DID Methods | 2020-07-29 | |||||||||||||||||||||||||||||||
| 234 | DID Methods | Ontology Foundation | did:near: | did:near: | NEAR uses readable account identifiers instead of a hash of a public key, and the accounts have some DID features, but not all. We have developed this specification to define a new DID method for hosting DIDs on the NEAR blockchain, also referred to as NEAR DID, and facilitate developers to work with related contracts. | https://github.com/ontology-tech/DID-spec-near/blob/master/NEAR/DID-Method-NEAR.md | Specification | NEAR | DID Methods | 2020-08-02 | ||||||||||||||||||||||||||||||
| 235 | DID Methods | China Academy of Information and Communications Technology (CAICT) | did:vaa: | did:vaa: | Blockchain Identifier Infrastructure (BIF) is a permissioned public blockchain aiming for creating a distributed trust management framework typical for internet ID service, and the [BIF blockchain](http://bidspace.cn/) is governed by China Academy of Information and Communications Technology (CAICT). CAICT is also the official issuing agency with Issuing Agency Code (IAC)——"VAA", given by ISO/IEC 15459. The IAC indicates an authorized qualification of distributing identifiers with own allocation rules. | https://github.com/caict-develop-zhangbo/vaa-method/blob/master/README.md | Specification | BIF | DID Methods | 2020-08-05 | ||||||||||||||||||||||||||||||
| 236 | DID Methods | Attila Aldemir | did:bba: | did:bba: | The `bba` DID method aims to enable the Ardor blockchain to act as a DPKI within the SSI ecosystem. It runs on the independent IGNIS child chain and utilizes Ardors Account Properties feature to manage DIDs and corresponding DID controllers. The Account Properties feature provides the possibility to tag an account with a small amount of data (160 characters). A DID controller is always represented in form of an Ardor account and is by default separated from the public keys (if present) embedded in a DID document. Think of a master key controlling the DID operations create, update and deactivate. A DID controller always corresponds to exactly one Ardor account, whereas one Ardor account can control multiple DIDs.<br><br>DID and DID document handling is decoupled so that multiple DID document storages can be defined and integrated to store DID document templates (DID documents without a DID reference). In its current state, the `bba` DID method defines only one storage type (Ardor Cloud Storage).<br>In the following, `bba` DID method compliant account properties are called DID attestations. An account property is `bba` DID method compliant if it aligns to the data model described in the DID Attestation Data Fields section and is self-set. A self-set account property is a property in which sender and receiver accounts are identical. | https://github.com/blobaa/bba-did-method-specification/blob/master/docs/markdown/spec.md | Specification | Ardor | DID Methods | 2020-08-31 | ||||||||||||||||||||||||||||||
| 237 | DID Methods | Hydra Hashgraph | did:morpheus | did:morpheus | Distributed ledger technologies (DLT, blockchain) are mostly used by cryptocurrencies, but their event ordering and decentralized consensus algorithms are useful for general purpose. Morpheus needs DLT for safe ordering DID updates and querying the historical state of a DID Document at any given point of time for signature validation. The main benefit of DLTs is that many parties with opposing interests run the infrastructure, therefore it is almost impossible to unilaterally control changes to the history and state of the ledger. | https://developer.iop.technology/w3c?id=iop-morpheus-did-method | Specification | IOP Global | DID Methods | |||||||||||||||||||||||||||||||
| 238 | DID Methods | Ontology Foundation | did:etho: | did:etho: | Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This ETHO DID method specification describes a new DID method, that is, ETHO DID and defines how Ethereum blockchain stores ETHO DIDs and their corresponding DID documents, and how to do CRUD operations on ETHO DID documents. | https://github.com/ontology-tech/DID-method-specs/blob/master/did-etho/DID-Method-etho.md | Specification | Ethereum | DID Methods | 2020-08-14 | ||||||||||||||||||||||||||||||
| 239 | DID Methods | Ontology Foundation | did:bnb: | did:bnb: | Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Binance DID method specification describes a new DID method, that is, Binance DID and defines how Binance Smart Chain stores Binance DIDs and their corresponding DID documents, and how to do CRUD operations on Binance DID documents. | https://github.com/ontology-tech/DID-method-specs/blob/master/did-bnb/DID-Method-bnb.md | Specification | Binance Smart Chain | DID Methods | 2020-08-14 | ||||||||||||||||||||||||||||||
| 240 | DID Methods | Ontology Foundation | did:celo: | did:celo: | This Celo DID method specification describes a new DID method, that is, Celo DID and defines how Celo blockchain stores Celo DIDs and their corresponding DID documents, and how to do CRUD operations on Celo DID documents. | https://github.com/ontology-tech/DID-method-specs/blob/master/did-celo/DID-Method-celo.md | Specification | Celo | DID Methods | 2020-08-14 | ||||||||||||||||||||||||||||||
| 241 | DID Methods | Ontology Foundation | did:klay: | did:klay: | Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Klaytn DID method specification describes a new DID method, that is, Klaytn DID and defines how Klaytn blockchain stores Klaytn DIDs and their corresponding DID documents, and how to do CRUD operations on Klaytn DID documents. | https://github.com/ontology-tech/DID-method-specs/blob/master/did-klay/DID-Method-klay.md | Specification | Klaytn | DID Methods | 2020-08-14 | ||||||||||||||||||||||||||||||
| 242 | DID Methods | Ontology Foundation | did:trx: | did:trx: | This TRON DID method specification describes a new DID method, that is, TRON DID and defines how TRON blockchain stores TRON DIDs and their corresponding DID documents, and how to do CRUD operations on TRON DID documents. | https://github.com/ontology-tech/DID-method-specs/blob/master/did-trx/DID-Method-trx.md | Specification | TRON | DID Methods | 2020-08-14 | ||||||||||||||||||||||||||||||
| 243 | DID Methods | GRGBanking Blockchain Express | did:grg: | did:grg: | GRG did document security authentication is based on the cryptography algorithm. A signature is used to verify that the claim is from a trusted did user. What should be noted is the authenticity verification of the issuer. An alliance blockchain maintained by an official organization is designed and used. In the alliance chain, the did document of the certification authority should be stored, and its did ID number should be displayed on the official website of the relevant organization. Therefore, the verifier can verify claims based on this information. | https://github.com/GrgChain/DID-method-specs/blob/master/README.md | Specification | GrgChain | DID Methods | 2020-08-01 | ||||||||||||||||||||||||||||||
| 244 | DID Methods | 51nodes GmbH | did:schema: | did:schema: | The Schema Registry DID Method aims to provide unique and universal identification for schemas in multiple formats hosted on multiple storage mechanisms or networks. | https://github.com/51nodes/schema-registry-did-method/blob/master/README.md | Specification | Portable, IPFS, evan.network | DID Methods | 2020-08-26 | ||||||||||||||||||||||||||||||
| 245 | DID Methods | CCG | did:key | Rick Astley, Manu Sporny, Dmitri Zagidulin, Dave Longley, Orie Steele | did:key | Ledger independent DID method based on public/private key pairs.<br><br>While DLT-based DID Methods have great decentralization characteristics, and some of the more centralized DID Methods provide strong system control guarantees, the general approaches tend to be expensive to setup and operate. Some use cases requiring DIDs do not need the guarantees provided by these heavy-weight systems. For example, a DID that will only be used for a single, ephemeral interaction might not need to be registered, updated, or deactivated. It is for this class of use cases that the did:key method exists | https://w3c-ccg.github.io/did-method-key/ | Specification | Portable, IPFS, evan.network | DID Methods | 2022-09-02 | |||||||||||||||||||||||||||||
| 246 | DID Methods | CCG | did:key | did-key-creator published | This has been tested to create did:keys from the P-256,P-384, and P-521 curves specified in https://github.com/w3c-ccg/did-method-key and https://w3c-ccg.github.io/did-method-key/ | This is a library for converting public keys to the did:key format. Latest version: 1.2.0, last published: 7 months ago. Start using did-key-creator in your project by running `npm i did-key-creator`. There is 1 other project in the npm registry using did-key-creator. | https://www.npmjs.com/package/did-key-creator | Code | Portable, IPFS, evan.network | DID Methods | 2022-11-03 | |||||||||||||||||||||||||||||
| 247 | DID Methods | Crates | Tomislav Markovski | did:key | Rust implementation of the did:key method | This crate is intended to provide basic support for did:key methods. It has no external dependencies and can be compiled for any target. It was originally designed for use with DIDComm Extension for gRPC, but we recognized it may be useful if this was an independent library | https://crates.io/crates/did-key | Code | Portable, IPFS, evan.network | DID Methods | 2022-11-28 | |||||||||||||||||||||||||||||
| 248 | DID Methods | Tryon | did:tyron: | Julio, Cabrapan Duarte | did:tyron: | Tyronzil is the W3C Decentralized Identifier Method of the Tyron Self-Sovereign Identity Protocol. You can find it published at the W3C DID Specification Registries, and it is the first DID Method of the Zilliqa blockchain - funded by ZILHive Innovation grants. | https://www.tyronzil.com/ | Specification | Zilliqa | DID Methods | ||||||||||||||||||||||||||||||
| 249 | DID Methods | Persistent Systems, R3 | did:corda: | Nitesh Solanki, Moritz Platt, Pranav Kirtani | did:corda: | To understand the environment in which the Corda DID method operates, the permissioned nature of a Corda network and the point-to-point approach to data replication must be taken into account. While parties in permissionless blockchains remain anonymous and can join and leave at will, any Corda network utilizes a standard PKIX infrastructure for linking public keys to identities [corda-whitepaper]. As such, individually deployed entities in the network – nodes – have a strong notion of identity. This concept is instrumental in network communication. Similarly, the data-replication model implemented in Corda is different to that of a conventional public blockchain, which makes all in-ledger data visible to all network participants. In Corda, data are distributed to a configurable subset of network members only.<br><br>The Corda DID method operates in an environment where multiple nodes form a consortium in order to replicate decentralized identity data (cf. figure 1). These consortium nodes replicate decentralized identifier documents to form a network-wide and, ultimately, consistent view of the unity of decentralized identifiers, using the Corda DID method. | https://htmlpreview.github.io/?https://github.com/persistentsystems/corda-did-method/blob/master/corda_did_method.html | Specification | Corda | DID Methods | 2020-09-21 | |||||||||||||||||||||||||||||
| 250 | DID Methods | Space Elephant | did:uns: | https://docs.uns.network/ | did:uns: | The goal of this method is to work in tandem with other, more complex DID methods based on the same blockchain. Uns.network is dedicated to the management of Non Fungible Tokens (NFT). The first type of NFT that it supports is [@uniknames](https://docs.unikname.com/), human-readable identifiers. Just like any other tokens, @uniknames can be bought or exchanged, but they can also be linked to public properties the owner wishes to advertise, or used to connect to compliant websites in a private and secure fashion, among other things. The `unik` DID method associates a DID to these NFT tokens, using uns-did as controllers. | https://github.com/unik-name/did-method-spec/blob/main/did-uns/UNS-DID-Specification.md | Specification | UNS Network | DID Methods | NFT | 2020-10-16 | ||||||||||||||||||||||||||||
| 251 | DID Methods | MediBloc | did:panacea: | did:panacea: | Panacea is a public blockchain built by MediBloc to reinvent the healthcare experience. Panacea also supports DID operations. DIDs are created and stored in the Panacea, and they are used with verifiable credentials. | https://github.com/medibloc/panacea-core/blob/master/docs/did.md | Specification | Panacea | DID Methods | 2020-10-10 | ||||||||||||||||||||||||||||||
| 252 | DID Methods | Hyperledger Foundation | did:indy: | did:indy: | Indy is a public ledger designed specifically and only for privacy-preserving self-sovereign identity. A Hyperledger Indy ledger is designed specifically to enable the use of verifiable credentials, allowing credential issuers to publish data necessary for issuing verifiable credentials and constructing presentations from those verifiable credentials. This specification covers how DIDs on an Indy ledger are managed and the operations for creating, reading, updating, and deleting DIDs. | https://github.com/hyperledger/indy-did-method | Specification | Hyperledger Indy | DID Methods | 2023-02-23 | ||||||||||||||||||||||||||||||
| 253 | DID Methods | IDCommons | Stephen Curran | did:indy: | IIW | The did:indy DID Method - Future Indy Ledgers | Getting involved with this work: | https://iiw.idcommons.net/4I/_The_did:indy_DID_Method_-_Future_Indy_Ledgers | Session Notes | Hyperledger Indy | DID Methods | 2021-05-06 | ||||||||||||||||||||||||||||
| 254 | DID Methods | BCGov | Stephen Curran | did:indy: | did:indy Presentation | - Namespaced DIDs useful across all Indy instances<br>- Indy network discovery<br>- Full DIDDoc support<br>- Namespaced identifiers for other Indy objects (schemas, etc.)<br>- Support for important resolution parameters<br>- E.g. version-id, version-time, resource<br><br>Nice to have (but not likely to be there):<br>- Cross-ledger registration of networks for discovery<br>- Support for KERI identifiers on Indy networks<br><br>Getting involved with this work:<br>- [HackMD Document](https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw) with current spec<br>- Home of future spec: [indy-did-method](https://github.com/hyperledger/indy-did-method)<br>- [Meeting Wiki](https://wiki.hyperledger.org/display/indy/Indy%2BDID%2BMethod%2BSpecification) and schedule<br>- Hyperledger [indy-did-method](https://chat.hyperledger.org/channel/indy-did-method) chat channel | https://docs.google.com/presentation/d/1c5K7E5CRx9ANuwmVBIyFVG5hJ4lH0EyW-wkmraLivBI/edit?usp%3Dsharing | Presentation | Hyperledger Indy | DID Methods | 2021-04-20 | |||||||||||||||||||||||||||||
| 255 | DID Methods | Blockchain Commons | did:onion: | did:onion: | 🧅 part of the torgap technology family<br>DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption. We propose using a new DID method that allows them to bootstrap trust using a Tor Hidden Service's existing reputation.<br><br>we'd like to review more with our community how close we want to keep did:onion to did:web, and if we want to incorporate some elements of did:peer or KERI or to leverage services like Open Time Stamps. | http://htmlpreview.github.io/?https://raw.githubusercontent.com/BlockchainCommons/did-method-onion/main/index.html | Specification | Tor | DID Methods | 2021-08-06 | ||||||||||||||||||||||||||||||
| 256 | DID Methods | Ceramic | did:nft: | did:nft: | The NFT DID Method converts any non-fungible token on any blockchain into a decentralized identifier where the owner of the NFT is the controller of the DID. This is achieved by using the Chain Agnostic Improvement Proposals to describe NFT assets and blockchain accounts, as well as the Ceramic network to find the DID associated with the owner of the NFT. | https://github.com/ceramicnetwork/CIPs/blob/main/CIPs/cip-94.md | Specification | Ethereum | DID Methods | 2021-02-12 | ||||||||||||||||||||||||||||||
| 257 | DID Methods | Gimly | did:eos: | did:eos: | 1. Identity - the management of accessible public key infrastructure and identifies. Decentralized Identifiers is the W3C standard that allows this. Compliance with this standard allows application layers to interoperate without a need to understand the base layer decentralised protocols that power identities.<br>2. Application - use of the identity layer to interact and provide meaningful, secure and verifiable data communications and interaction. The Verifiable Credentials W3C standard is the most prominent and adopted standard here which is a data structure and message protocol allowing people and organisations to securely and in a verifiable way send and verify information about themselves "credentials" to each other. DIDComm is another important application layer that uses DID methods to communicate between SSI identities. | https://github.com/Gimly-Blockchain/eosio-did-spec | Specification | EOS | DID Methods | 2021-06-30 | ||||||||||||||||||||||||||||||
| 258 | DID Methods | Gimly | did:eos: | The EOSIO DID method specification | We have been working with the [Decentralised Identity Foundation](https://identity.foundation) to shape this specification, and also want to thank the [W3C Credentials Community Group](https://www.w3.org/community/credentials/) for their support in the creation of the [Verifiable Condition](https://github.com/Gimly-Blockchain/verifiable-conditions) type, a necessary component to create the EOSIO DID document to represent EOSIO account permissions. | Gimly has built a full draft of the EOSIO Decentralised Identifier (DID) method specification. This specification guides the implementation of DIDs on EOSIO powered blockchains. | https://www.gimly.io/blog/the-eosio-did-method-specification | Post | EOS | DID Methods | 2021-04-02 | |||||||||||||||||||||||||||||
| 259 | DID Methods | SpruceID | did:did: | https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0026.html | did:did: | DID Identity DID (DID) DID method<br><br>Spruce announces did:did, a DID method based on Decentralized Identifiers (DIDs). We hope the community will find this useful to help increase adoption and interoperability of Decentralized Identity technology. | https://github.com/spruceid/did-did/ | Specification | humor | DID Methods | 2021-04-01 | |||||||||||||||||||||||||||||
| 260 | DID Methods | SpruceID | did:undid: | did:undid: | did:un-did is a DID method that enables using any valid Decentralized Identifier (DID) as a did:un-did DID, but more importantly it un-does the did that did:did did method performs.<br><br>*Clarification, a few week ago we shared about the [DID:DID](https://did-did.spruceid.com/) method. [April Fools Joke](https://en.wikipedia.org/wiki/April_Fools%2527_Day_RFC)!!! Here’s yet another DID method in the series.* | https://did-undid.github.io/did-undid/ | Specification | humor | DID Methods | 2021-04-01 | ||||||||||||||||||||||||||||||
| 261 | DID Methods | SpruceID | did:doge: | did:doge: | We draw heavily from prior work by Christopher Allen and Kim Hamilton Duffy within the W3C Credentials Community Group on the BTCR DID Method due to strong architectural similarities between the Bitcoin and Dogecoin blockchains.<br><br>However, there are some key differences that enable new privacy-preserving benefits. Namely, the did:doge method-specific identifier is the Base58Check-encoded Dogecoin address itself, allowing for DID usage even in the absence of any public transaction histories and only relying upon them for rotation events for verification methods and service endpoints. | https://spruceid.github.io/did-doge/index.html | Specification | Dogecoin | DID Methods | 2023-05-04 | https://github.com/spruceid/did-doge | |||||||||||||||||||||||||||||
| 262 | DID Methods | SpruceID, TQ Tezos | did:tz: | did:tz: | did:tz is a multi-modal DID method design with many offchain, on-chain, and side-chain/L2 use cases in mind. A valid Tezos address (controlled by a private key from any of 3 supported curves) can control an "implicit" DID document (generatively created from the address like a did:key), an "onchain" DID document (published via smart contract on any Tezos ledger), or have "patches" applied to it that are published and governed by a closed network or authority (including, for example, a sidetree network). In particular, this third option has not been specified in any detail, and we would be particularly curious to hear from implementers of such systems before further specifying it. | https://github.com/w3c-ccg/did-tz | Specification | Tezos | DID Methods | 2022-01-13 | ||||||||||||||||||||||||||||||
| 263 | DID Methods | SpruceID, TQ Tezos | did:tz: | Decentralized Identity with the Tezos DID Method | [Spruce](https://www.spruceid.com/) and [TQ Tezos](https://tqtezos.com/) are jointly releasing the [draft specification](https://did-tezos.spruceid.com/) and [initial implementation](https://github.com/spruceid/did-tezos) of [Decentralized Identifiers (DIDs)](https://www.w3.org/TR/did-core/) based on the Tezos blockchain. | A DID Method geared for privacy, formal verification, and scaling to billions of identifiers by using off-chain updates. Spruce and TQ Tezos are jointly releasing the draft specification and initial… | https://sprucesystems.medium.com/decentralized-identity-with-the-tezos-did-method-d9cf6676dd64 | Post | Tezos | DID Methods | 2021-03-03 | |||||||||||||||||||||||||||||
| 264 | DID Methods | Unisot | did:unisot: | did:unisot: | The UNISOT DID method uses the Bitcoin SV blockchain to generate DIDs as well as potentially store the associated DID documents. The method allows for storage of DID documents on-chain as well as off-chain depending on the business use case scenario. | https://gitlab.com/unisot-did | Specification | Portable | DID Methods | 2020-11-25 | ||||||||||||||||||||||||||||||
| 265 | DID Methods | Unisot | Annemie Bergmans | EBSI, did:unisot | ESSIF, GDPR | UNISOT DID approved by W3C | We are proud to have UNISOT ID (did:unisot) listed at the Decentralized Identity Foundation (DIF). As part of our commitment to open technologies and global interoperability we have presented our DID schema (did:unisot) to the Decentralized Identity Foundation (DIF) and supplied a driver for their Universal DID Resolver which can be accessed at: [https://resolver.identity.foundation/](https://resolver.identity.foundation/). With this anyone can resolve a UNISOT DID Document in a trusted and easy way. | The UNISOT DID is compliant with W3C specifications | https://unisot.com/unisot-did-approved-by-w3c/ | Post | Portable | DID Methods | 2021-05-25 | |||||||||||||||||||||||||||
| 266 | DID Methods | SecureKey | did:orb: | did:orb | Orb is a decentralized identifier (DID) method based on a federated and replicated Verifiable Data Registry (VDR). The decentralized network consists of Orb servers that write, monitor, witness, and propagate batches of DID operations. The batches form a graph that is propagated and replicated between the servers as content-addressable objects. These content-addressable objects can be located via both domain and distributed hash table (DHT) mechanisms. Each Orb witness server observes a subset of batches in the graph and includes them in their ledgers (as append-only Merkle Tree logs). The servers coordinate by propagating batches of DID operations and by monitoring the applicable witness servers' ledgers. The Orb servers form a decentralized network without reliance on a common blockchain for coordination. | https://trustbloc.github.io/did-method-orb/ | https://trustbloc.github.io/did-method-orb/diagrams/flow-model.svg | Specification | Federated | DID Methods | 2022-03-21 | |||||||||||||||||||||||||||||
| 267 | DID Methods | SecureKey | did:orb: | Orb | Orb implements the following specifications: [did:orb](https://trustbloc.github.io/did-method-orb/), [Activity Anchors](https://trustbloc.github.io/did-method-orb/). The did:orb method is based on the Sidetree specification and Activity Anchors is based on the ActivityPub and ActivityStreams specifications.<br><br>Please see [Read the Docs](https://trustbloc.readthedocs.io/en/latest/orb/index.html) for more details on Orb | A DID method implementation that extends the Sidetree protocol into a Fediverse of interconnected nodes and witnessed using certificate transparency. Spec: https://trustbloc.github.io/did-method-orb/ - GitHub - trustbloc/orb: A DID method implementation that extends the Sidetree protocol into a Fediverse of interconnected nodes and witnessed using certificate transparency. Spec: https://trustbloc.github.io/did-method-orb/ | https://github.com/trustbloc/orb | Code | DID Methods | Trustbloc | ActivityPub, ActivityStreams, Sidetree | 2023-05-25 | ||||||||||||||||||||||||||||
| 268 | DID Methods | SecureKey | did:orb: | SecureKey’s New Ledger-Agnostic did:orb | did:orb that decouples DIDs from ledgers while maintaining trust and security. SecureKey is leveraging standard and open-source peer-to-peer protocols like ActivityPub, data structures like verifiable credentials content-addressed storage like IPFS, and distributed trust services like the Google Trillian project to build a peer-to-peer trust network. | Decentralized Identifiers are usually thought of as being bound to a particular ledger and blockchain, such as SecureKey’s first DID Method. | https://securekey.com/securekeys-new-ledger-agnostic-solution-orb-helps-solve-decentralized-identifier-challenges/ | Post | DID Methods | ActivityPub, IPFS, verifiable credentials | 2021-06-10 | |||||||||||||||||||||||||||||
| 269 | DID Methods | CCG Mailing List | Troy Ronda | did:orb:, | did:orb slides Troy Ronda (SecureKey) | * Decouple witness ledgers from the critical path.<br>- Allow for Trust but Verify model.<br>- Leverage the Certificate Transparency model<br>- Witnesses observe VDR objects and promise to include in their ledgers.<br>- Provide a signed timestamp and a maximum merge delay.<br>- Enable monitoring to ensure witnesses follow their promises.<br>- Use trusted Witness (and origin) timings to resolve late publishing.<br>- Use origin to enable observers to know if they have the latest operations. | https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0017.html | Presentation | DID Methods | 2021-03-03 | ||||||||||||||||||||||||||||||
| 270 | DID Methods | Trusted Digital Web | Michael Herman | did:object | This "DID Object" Decentralized Identifier Method Namespace Specification ("DID Object" DID Method Namespace Specification) defines the end-to-end lifecycle of DID Identifiers and DID Documents for "DID Objects", a key feature of the Fully Decentralized Objects (FDOs) Framework, implemented by the Trusted Digital Web. | Trusted Digital Web (TDW): Trusted Digital Assistant (TDA), Trusted Resource Agent (TRA), Key Management Agent (KMA), and Verifiable Data Agent (VDA) - TrustedDigitalWeb/did-object.md at master · mwherman2000/TrustedDigitalWeb | https://github.com/mwherman2000/TrustedDigitalWeb/blob/master/specifications/did-methods/did-object.md | Specification | DID Methods | 2022-01-26 | ||||||||||||||||||||||||||||||
| 271 | DID Methods | Personal | Bob Wyman | did:tag | The did:tag DID method enables any controller of an HTTP accessible domain or subdomain, or of an email address, to create unique, interoperable, persistent DIDs with minimal dependencies on other technologies or systems. By leveraging a subset of the tagURI specification [RFC4151], the did:tag DID method enables the creation of DIDs which are "unique across space and time while being tractable to humans," without preventing the creation of DIDs which are largely intractable to humans. did:tag DIDs can be resolved either synchronously, via the web, or asynchronously, via email or other defined alternative resolution services. | ROUGH DRAFT: did:tag Decentralized Identifier Method Specification - GitHub - bobwyman/did_method_tag: ROUGH DRAFT: did:tag Decentralized Identifier Method Specification | https://github.com/bobwyman/did_method_tag | Specification | DID Methods | 2021-11-02 | ||||||||||||||||||||||||||||||
| 272 | DID Methods | CCG Mailing List | Bob Wyman | re: Using Email as an Identifier | There are quite a number of issues with using email addresses as identifiers, or parts of identifiers, and I'm hoping that discussion and development of the did:tag method will illuminate those issues and potentially find solutions for them. | https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0065.html | Discussion | DID Methods | 2021-11-12 | |||||||||||||||||||||||||||||||
| 273 | DID Methods | waltid, transmute | did:key | did:jwk | did:jwk is a deterministic transformation of a JWK into a DID Document. | https://github.com/quartzjer/did-jwk/blob/main/spec.md | Specification | DID Methods | JWK | 2022-04-14 | ||||||||||||||||||||||||||||||
| 274 | DID Methods | CCG | did:pkh | allows most if not all blockchain accounts to instantly leverage an existing identity/account and deploy a W3C Decentralized Identifier from it in a standards-conformant way. This "DID-wrapping" of an existing identifier can be used in combination with other DID-compatible technologies, such as W3C Verifiable Credentials or Authorization Capabilities, and produce proper signature-suite definitions, such as "metamask-signing" (off-chain signing by externally-owned accounts, i.e., personal wallets, according to the eip712 protocol). | We would like to open up the design process for did:pkh to a more open and consultative/deliberative conversation in the open. - did-pkh/did-pkh-method-draft.md at main · w3c-ccg/did-pkh | https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md | Specification | DID Methods | 2023-01-27 | |||||||||||||||||||||||||||||||
| 275 | DID Methods | Verite | did:pkh | Verification Patterns, Part 2 | explains the [did:pkh](https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md)/[CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md%23simple-summary) variation for Verite data models and flows, which provides an entry path for wallets that may not support sufficient functionality for emerging decentralized identity patterns | Exploration of Verite verification patterns, with a focus on non-DID wallets. Part 2 in a 2-part series | https://docs.centre.io/blog/verification-patterns-2 | https://docs.centre.io/assets/images/verifier_cacao-92d2ea3dba6784af5ecb1bf28b56e52b.jpg | Post | DID Methods | 2022-07-27 | |||||||||||||||||||||||||||||
| 276 | DID Methods | Veramo Labs | did:ens | 1. to wrap existing ENS names as DIDs to be interoperable with applications relying on Decentralized Identifiers<br>2. to define a canonical way to augment ENS names with DID capabilities such as services and verification methods. | https://github.com/veramolabs/did-ens-spec | Specification | DID Methods | 2021-10-05 | ||||||||||||||||||||||||||||||||
| 277 | DID Methods | uPort | Oliver Terbu | ENS names are Decentralized Identifiers (DIDs) | The specification is extensible by design which means new types of services, verification materials and other features can be supported. In the core, the specification contains a simple interface to resolve a DID Document from a DID (similar to an Ethereum Account from an ENS name) by anyone who knows the DID of the user. The DID Document will then contain the relevant information to enable use cases such as sign up, sign in, data encryption, secure communication, verifiable authorship and data provenance etc. Since DIDs are URI-compliant, they also make perfect sense for web ontologies. | https://medium.com/uport/ens-names-are-decentralized-identifiers-dids-724f0c317e4b | Post | DID Methods | 2021-10-19 | |||||||||||||||||||||||||||||||
| 278 | DID Methods | TIFAC-CORE in Cyber Security | Ramaguru Radhakrishnan, Amrita Vishwa Vidyapeetham | did:avvcyber: | TIFAC-CORE in Cyber Security, Amrita School of Engineering, Amrita Vishwa Vidyapeetham Coimbatore is Center of Relevance and Excellence (CORE) in Cyber Security. The Center is working toward Cryptography, Visual Cryptography, Steganography, Cyber Forensics, Machine Learning and Blockchain Technology. There are multiple projects being worked across domains where we are using DIDs. did:avvcyber: is a dedicated DID created for all our Blockchain Projects from 2022. | https://github.com/Amrita-TIFAC-Cyber-Blockchain/DID-AVVCYBER/blob/main/did-avvcyber-v1.md | Code | DID Methods | 2022-01-01 | |||||||||||||||||||||||||||||||
| 279 | W3C | W3C | World Wide Web Consortium (W3C) | The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web. | https://w3.org | site | Main | |||||||||||||||||||||||||||||||||
| 280 | W3C | ICANN Wiki | W3C - ICANN WIki | First started as an IETF application area at the beginning of 1990, the Web standard stack, given its foreseen volume and applicative nature on top of the Internet protocols, quickly spun off its own forum. The W3C then laid the foundations of the Web with the development of HTML 4 and XML at the end of the last century. It still works closely with IETF today, on the HTTP or URL specifications and in other areas of common interest (e.g. crypto, security, video). | https://icannwiki.org/W3C | entry | Main | history | 2022-04-05 | |||||||||||||||||||||||||||||||
| 281 | W3C | W3C | World Wide Web Consortium (W3C) | an international community where Member organizations, a full-time staff, and the public work together to develop Web standards. Led by Web inventor and Director Tim Berners-Lee and CEO Jeffrey Jaffe, W3C's mission is to lead the Web to its full potential. | https://www.w3.org/Consortium/ | page | Main | 2022-06-01 | https://github.com/w3c | https://twitter.com/w3c | https://www.linkedin.com/company/w3c/ | |||||||||||||||||||||||||||||
| 282 | W3C | W3C | W3C Mission | On 29 August 2012 five leading global organizations jointly signed an agreement to affirm and adhere to a set of Principles in support of The Modern Paradigm for Standards; an open and collectively empowering model that will help radically improve the way people around the world develop new technologies and innovate for humanity. | https://www.w3.org/Consortium/mission | page | Main | history | 2023-01-01 | |||||||||||||||||||||||||||||||
| 283 | W3C | W3C | Facts About W3C | In 1989, Tim Berners-Lee invented the World Wide Web (see the original proposal). He coined the term "World Wide Web," wrote the first World Wide Web server, "httpd," and the first client program (a browser and editor), "WorldWideWeb," in October 1990. He wrote the first version of the "HyperText Markup Language" (HTML), the document formatting language with the capability for hypertext links that became the primary publishing format for the Web. His initial specifications for URIs, HTTP, and HTML were refined and discussed in larger circles as Web technology spread. | https://www.w3.org/Consortium/facts.html | page | Main | history | 2023-01-01 | |||||||||||||||||||||||||||||||
| 284 | W3C | W3C | Standards - W3C | W3C standards define an Open Web Platform for application development that has the unprecedented potential to enable developers to build rich interactive experiences, powered by vast data stores, that are available on any device. Although the boundaries of the platform continue to evolve, industry leaders speak nearly in unison about how HTML5 will be the cornerstone for this platform. But the full strength of the platform relies on many more technologies that W3C and its partners are creating, including CSS, SVG, WOFF, the Semantic Web stack, XML, and a variety of APIs. | https://www.w3.org/standards/ | page | Main | 2021-01-01 | ||||||||||||||||||||||||||||||||
| 285 | W3C | W3C | W3C Workshop on Strong Authentication & Identity | The W3C Strong Authentication and Identity Workshop gathered experts in the space to explore the existing standards landscape, examine existing technology roadmaps, and identify potential future work for how strong identity and strong authentication should work on the web. The workshop explored aligning recent W3C specifications (WebAuthn, Verifiable Claims, Web Payments) and work that is ongoing in the W3C Credentials Community Group (DID, DIDAuth) along with the IETF and ISO, as well as other existing community standards such as IndieAuth, Open ID Connect, OAuth, and SAML. | https://www.w3.org/Security/strong-authentication-and-identity-workshop/report.html | page | W3C ID History | 2018-12-11 | ||||||||||||||||||||||||||||||||
| 286 | W3C | W3C | Tim Berners-Lee | A Public Identity | The world of the last few years has been buzzing with the need for personal privacy a world in which personal data is typically abused by large corporations on the (mistaken) belief that this is the only business model in a connected world. It seems to have got to the point where there has been so much focus on protecting the identity of an individual online that we have actually made it difficult, frustratingly and unnecessarily difficult, to actually claim a completely public identity online. | https://www.w3.org/DesignIssues/PublicIdentity.html | page | W3C ID History | 2018-01-19 | |||||||||||||||||||||||||||||||
| 287 | W3C | W3C | Call for Participation in Digital Identity Community Group | The mission of the W3C Digital Identity Community Group is to identify and resolve real world identity issues, to explore and build a more secure trusted digital identity ecosystem on internet for people, organizations and things fully controlling, protecting and expressing their identity. Our work focuses on the ecosystem’s scalability, interoperability, mobility, security and privacy. We intend to integrate interoperable identity solutions, systems and networks in our ecosystem. | https://www.w3.org/community/dic/2019/06/20/call-for-participation-in-digital-identity-community-group/ | Post | W3C ID History | 2019-06-20 | ||||||||||||||||||||||||||||||||
| 288 | W3C | W3C | The Platform for Privacy Preferences 1.1 (P3P1.1) Specification | This is the specification of the Platform for Privacy Preferences 1.1 (P3P 1.1). This document, along with its normative references, includes all the specification necessary for the implementation of interoperable P3P 1.1 applications. P3P 1.1 is based on the P3P 1.0 Recommendation and adds some features using the P3P 1.0 Extension mechanism. It also contains a new binding mechanism that can be used to bind policies for XML Applications beyond HTTP transactions. | https://www.w3.org/TR/P3P11/ | Specification | W3C ID History | 2018-08-30 | ||||||||||||||||||||||||||||||||
| 289 | W3C | W3C | Tim Berners-Lee 1998 | Web Design Issues - Identity | Identifiers - what is identified?<br>When XML is used to represent a directed laballed graph which is used to represent information about things, then one must be able to make statements about parts of an XML document, parts of the DLG (such as RDF nodes) and of course the objects described. | https://www.w3.org/DesignIssues/Identity.html | page | W3C ID History | 2009-08-27 | |||||||||||||||||||||||||||||||
| 290 | W3C | W3C | Identity Interoperability | TimBL's diagram at TPAC2012Over the years many different authentication systems have been developed. Each one proposes a method for an agent to prove his relation to an identifier - called a Principal. A Principal is a string that can be mapped to a URI, that usually refers to some network resource, which itself can then be linked to a subject. An LDP authorization system may authenticate agents that are allowed access to a resource using different types of Principals. This page lists a number of ways Authorization agents can prove identity of an agent using one Principal, with an ACL that may be using a different type of Principal. The aim is to gather such examples together in order to find an general theory that underpins these proofs. | https://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability | https://www.w3.org/2005/Incubator/webid/wiki/images/thumb/2/2f/IdentityInterop.jpg/250px-IdentityInterop.jpg | Post | W3C ID History | 2013-01-07 | |||||||||||||||||||||||||||||||
| 291 | W3C | W3C | Identity Definitions in the P3P Specification | The P3P Specification Working Group has taken the view point that most information referring to an individual is «identifiable» in some way. As with other important areas of the specification, the goal of the working group was to allow for a wide variety of understandings of identity in order to allow data collectors to best express their policy and users to make choices based on a definition of identity information that is important to them. (1) | https://www.w3.org/P3P/2003/09-identifiable.html | page | W3C ID History | 2006-11-13 | ||||||||||||||||||||||||||||||||
| 292 | W3C | W3C | IdentityWoman, Phillip J. Windley, Aldo Castaneda | IDCommons | Identity Rights Agreements and Provider Reputation | Abstract: While decentralized, user-centric identity systems provide hope that useful, secure identity systems may be possible on the Internet, ensuring that user data is protected in these system requires more than a technical solution. In this paper, we describe a project underway at Identity Commons to create a framework within which users can express their protection preferences (called identity rights agreements). Part of this project will establish a reputation system for identity providers and relying parties that engenders trust and lowers user risk. | IDENTITY COMMONS Position Paper | https://www.w3.org/2005/Security/usability-ws/papers/26-idcommons/ | page | W3C ID History | 2006-01-26 | |||||||||||||||||||||||||||||
| 293 | W3C | W3C | W3C Workshop on Identity in the Browser | Over the last ten years, for most end-users there has been no visible progress beyond cookie-managed usernames and passwords entered via HTML forms. Current password-based logins offers little value to the end-user, as they are forced to bear the onerous responsibility of remembering too many passwords or simply re-using low-security passwords. <br><br>As passwords and cookies are easily compromised, both web-site operators and users then expose themselves to massive security breaches. Despite the large amount of valuable standardization work on identity, it is unclear how user agents such as Web browsers can interact with both identity-consuming applications and server-side federated identity services, and many current identity specifications either assume or underspecify secure authentication in the browser. The key missing component to enable trusted identity on the Web is likely then to be found in user-centric cross-browser standards for secure authentication and session management. | https://www.w3.org/2011/identity-ws/report.html | Report | W3C ID History | 2011 | ||||||||||||||||||||||||||||||||
| 294 | W3C | W3C | Channy Yun | A draft charter of Web Identity | The W3C has prepared Web Identity working group and make a draft charter. As following is main track for works. | https://www.w3.org/community/webcryptoapi/2011/10/05/a-draft-charter-of-web-identity/ | Post | W3C ID History | 2011-10-05 | |||||||||||||||||||||||||||||||
| 295 | W3C | W3C | ISSUE-17: Identity, Agent, Person, Persona, Account etc. need clarifications | As for today we don't seem to have clear strategy on how to define and use Online Identity related concepts. | https://www.w3.org/Social/track/issues/17 | https://www.w3.org/2008/site/images/icons/atom | page | W3C ID History | 2015-03-03 | |||||||||||||||||||||||||||||||
| 296 | W3C | W3C | WebID | The W3C is still exploring better ways to do authentication, for example in the [2014 workshop on authentication](http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/Overview.html). The WebID is a Community Group, and anyone can start a Community Group. A Community Group does not necessarily reflect the endorsement of the W3C, but we encourage grassroots communities to experiment with technology that may become a future standard. | https://www.w3.org/wiki/WebID | https://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg | entry | W3C ID History | 2018-06-17 | |||||||||||||||||||||||||||||||
| 297 | W3C | W3C | USER IDENTITY ON THE WEB COMMUNITY GROUP | Currently, more and more services are created on the web and require information about you, me, all of us. Therefore, users have to give away a lot of information about themselves to many different services. The point is that the users lose control of their identity on the web, by filling a lot of forms (e.g., through subscriptions). Privacy on the Internet is extremely important and must remain. Personal information is used by services we, sometimes, don't even know about, and it is a real problem. The aim of this group would be to think about new ways to identify individuals over the internet using trusted web based identities embedded directly into the core protocols of the web. At the same time it is important to maintain equilibrium between total privacy and providing information when needed, which means, when the user wants to. | https://www.w3.org/community/w3id/ | org | W3C ID History | 2014-10-26 | ||||||||||||||||||||||||||||||||
| 298 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Naveen Agarwal, Miranda Callahan, Tyler Close, Travis McCoy, Chris Messina, Glen Murphy, Dirk Pranke | Identity in the Browser: Easy Wins and Guiding Principles | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_52.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 299 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Peter Alterman | NIH | National Strategy for Trusted Identities in Cyberspace - Requirements and Potential Use Cases | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_21.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 300 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Siddharth Bajaj, Slawek Ligier | Symantec | A Vision for Browser-Assisted Web Authentication | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_43.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 301 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Wendell Baker | Yahoo! | The Chained Identity Systems of Online Entertainment | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_14.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 302 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Dirk Balfanz | Identity in the Platform - Thinking Beyond the Browser | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_26.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 303 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Patrik Bichsel, Dave Raggett, Rigo Wenning | Web authentication is deeply flawed, and it is time to fix it | https://www.w3.org/2011/identity-ws/papers/bichsel-raggett-wenning.html | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 304 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Aaron Brauer-Rieke | Center for Democracy & Technology | Considering Browsers' Role in a User-Centric Online Identity Ecosystem: Privacy and Context | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_24.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 305 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | David W Chadwick, George Inman, Kristy Siu | University of Kent | Expression of Interest - Improving Identity Management on the Internet | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_12.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 306 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Francisco Corella, Karen P. Lewison | Pomcor | NSTIC, Privacy and Social Login | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_48.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 307 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | D. Crocker | Brandenburg InternetWorking | Tailored Signatures with DOSETA | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_1.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 308 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Vito Fabbrizio, Greg Kerr | AuthenTec | AuthenTec Online Open Authentication | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_34.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 309 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Phillip Hallam-Baker | Comodo Group | Account Management: A Deployment and Usability Problem | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_10.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 310 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Kaliya Hamlin, Mary Hodder | Personal Data Ecosystem Consortium | Empowering Individuals with Tools to Manage Their Personal Data for the Identity in the Browser | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_54.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 311 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Mike Hanson, Dan Mills, Ben Adida | Mozilla | Federated Browser-Based Identity using Email Addresses | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_25.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 312 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Dick Hardt | The Chicken, the Egg and the Rooster: Why Internet Identity is Still Unsolved | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_46.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 313 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Sam Hartman (Painless Security), Josh Howlett | JANET(UK) | Identity as a Platform Service | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_9.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 314 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Carl Hewitt | Looming private information fiasco versus the new cloud business model: The next generation will ask "Where were you when this was going down?" | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_45.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 315 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Brad Hill | Identity in the Browser - Avoiding Common Flaws | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_37.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 316 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Frederick Hirsch | Nokia | Importance and Impact of Requirements on Technical Solutions for Identity | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_31.html | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 317 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Jonas Hogberg | Ericsson | Mobile Provided Identity Authentication on the Web | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_20.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 318 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Maryann Hondo, Mary Ellen Zurko, Matthew Flaherty, Paula K. Austel, Sridhar Muppidi | IBM | The Nexus of Identity | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_35.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 319 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | John Hwang | Neustar | How to Improve the Security around the Mobile User Authentication Process? | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_6.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 320 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Phil Hunt | Oracle | Evolution of Identity in the Face of a New Lightweight Web Services Paradigm Shift | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_56.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 321 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Michael B. Jones | Microsoft | The Emerging JSON-Based Identity Protocol Suite | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_30.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 322 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Kevin Jones, Narm Gradiraju, Jack Matheson | Intel | Identity Security within Web Browsers | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_8.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 323 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Vladimir Katardjiev, Goran Eriksson | LM Ericsson AB | Selected issues with web identity mechanisms and a possible way forward | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_18.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 324 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | James Klo, Marie Bienkowski | SRI International | Identity in the Federal Learning Registry | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_27.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 325 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | John Linn | RSA/EMC | Goals, Constraints, and Issues for Identity in the Browser | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_2.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 326 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Ben Livshits | Microsoft | Browser Personas: Towards a Reasonable Middle Ground | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_40.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 327 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Brian Mcginnis, Johnny Bufu, Vlad Skvortsov | Echo | Backplane Protocol and Identity Scenario | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_49.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 328 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Miguel A. Monjas, Jose M. del Alamo, Juan-Carlos Yelmo, Jonas Hogberg | Ericsson | Privacy Delegate: a browser-based tool for privacy self-management in social networks | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_19.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 329 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | RL "Bob" Morgan | University of Washington, InCommon | Browser support for identity federation with many identity providers | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_29.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 330 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Yutaka Oiwa, Tatsuya Hayashi, Boku Kihara | AIST | Reparing HTTP authentication for Web security | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_36.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 331 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Mike Perry | The Tor Project | Bridging the Disconnect Between Web Privacy and User Perception | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_38.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 332 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Yngve Pettersen | Opera Software ASA | Improving password managers and multidevice synchronization | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_47.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 333 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Anders Rundgren | PrimeKey Solutions AB | Two-factor Authentication for the Cloud | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_11.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 334 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Jeff Sayre, Henry Story | The WebID Protocol & Browsers | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 335 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Stephen Schultze | Princeton University | Thoughts on Trust Infrastructure, User Interface, and Legal Issues | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_50.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 336 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Dan Schutzer | Financial Services Roundtable/BITS | Statement of Interest and Requirements for W3C Workshop on Identity in the Browser | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_33.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 337 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | David Singer | Apple | Do you know who I am? | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_51.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 338 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Thomas J. Smedinghoff, Wildman Harrold | Allen & Dixon | Building the Legal Framework for Browser-Enabled Identity | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_39.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 339 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Manu Sporny, David Longley, David I. Lehn, Mike Johnson | Digital Bazaar | A WebID Implementation in Pure JavaScript and Flash | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_7.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 340 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Andy Steingruebl, Jeff Hodges | PayPal | Identity in the Browser: Putting the Cart Before the Horse | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_55.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 341 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Olivier Thereaux, Mo McRoberts, Richard Northover | British Broadcasting Corporation | A usable identity management system for the Digital Public Space | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_17.html | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 342 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Don Thibeau | OpenID Foundation, OIX | On OIX and NSTIC | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_53.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 343 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | John Tolbert | The Boeing Company | Digital Identity in Perspective | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_57.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 344 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Paul Trevithick | Azigo | Identity In The Browser at 5. Lessons Learned | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_41.html | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 345 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Hannes Tschofenig, Barry Leiba, Blaine Cook, Rob van Eijk | Browser Support for the Open Authorization (OAuth) Protocol | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_32.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 346 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Sean Turner, Stephen Farrell, Peter Saint-Andre | IETF | The Need for a Web Security API | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 347 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | M. Vanderveen | Server Authentication with DNSSEC | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_3.pdf | Paper | ID in the Browser 2011 | 2011 | |||||||||||||||||||||||||||||||
| 348 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Yu Wang, Aanchal Gupta | Yahoo! | Browser Assisted Identity Management | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_15.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 349 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Mark Watson, Mitch Zollinger, Wesley Miaw | Netflix | Position paper from Netflix, Inc. | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_23.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 350 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Nicolas Williams | Cryptonector | GSS-REST, a Proposed Method for HTTP Application-Layer Authentication | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_16.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 351 | W3C | W3C | https://www.w3.org/2011/identity-ws/papers.html | Craig H. Wittenberg | Microsoft | Consumer Third Party Authentication: Challenges and Potential Solutions | https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_42.pdf | Paper | ID in the Browser 2011 | 2011 | ||||||||||||||||||||||||||||||
| 352 | JSON-LD | json-ld.org | JSON-LD (json-ld.org) | Data is messy and disconnected. JSON-LD organizes and connects it, creating a better Web. | https://json-ld.org/ | site | Main | |||||||||||||||||||||||||||||||||
| 353 | JSON-LD | json-ld.org | JSON-LD Playground (json-ld.org) | The JSON-LD Playground is a web-based JSON-LD viewer and debugger. If you are interested in learning JSON-LD, this tool will be of great help to you. Developers may also use the tool to debug, visualize, and share their JSON-LD markup. | https://json-ld.org/playground/ | tool | Main | |||||||||||||||||||||||||||||||||
| 354 | JSON-LD | Moz | Alexis Sanders | JSON-LD for Beginners | JSON-LD stands for JavaScript Object Notation for Linked Data, which consists of multi-dimensional arrays (think: list of attribute-value pairs). <br><br>It is an implementation format for structuring data analogous to Microdata and RDFa. Typically, in terms of SEO, JSON-LD is implemented leveraging the Schema.org vocabulary | Structured data is a must-have for many sites, but it can be hard to get a handle on the technical considerations. Learn the important basics of JSON-LD and how to ramp up your education as you apply it. | https://moz.com/blog/json-ld-for-beginners | Post | Main | 2017-02-09 | ||||||||||||||||||||||||||||||
| 355 | JSON-LD | json-ld.org | Why JSON-LD | JSON-LD is able to accomplish the same thing, but does not require HTML. It can exist in and of itself. In short, JSON-LD can be inserted into your web page without disrupting the current content or HTML. | https://jsonld.com/why-json-ld/ | Post | Main | 2015-09-26 | ||||||||||||||||||||||||||||||||
| 356 | JSON-LD | Transmute | Orie Steele | On JSON-LD and the semantics of Identity | In this post, we’ll explore how JSON-LD is used in a number of contexts including decentralized identity and verifiable credentials. We’ll also cover the basics of what you should know before using JSON-LD and how you can contribute to software and standards that rely on it. | https://medium.com/transmute-techtalk/on-json-ld-and-the-semantics-of-identity-42d051d3ce14 | Post | Main | 2020-01-06 | |||||||||||||||||||||||||||||||
| 357 | JSON-LD | DataLanguage | https://news.ycombinator.com/item?id=17021939 | Publishing JSON-LD for Developers | A case for publishing JSON-LD regardless whether you are working with linked data or RDF, with some simple examples<br><br>JSON-LD has been among us for several years now, its adoption is increasing, but I suspect not as fast as it probably should. JSON-LD arose out of the RDF community, subsequently adopted as a W3C standard, as a pattern for representing RDF and linked data (hence 'LD') as JSON, with a key aim of making RDF much easier to consume for developers. | https://datalanguage.com/news/publishing-json-ld-for-developers | https://images.datalanguage.com/EHpzmIaNh/mb-jsonld-800.png?w=1200&h=630 | Post | Main | 2018-04-27 | ||||||||||||||||||||||||||||||
| 358 | JSON-LD | sitechecker | What Is JSON-LD Markup and Why Is It Better than Schema.org? | If you understand how to use schema.org, but do not dare to mark pages up because of the complexity of the process, this article is for you. There is an effective and easy-to-use alternative - the JSON-LD format. | https://sitechecker.pro/json-ld-markup/ | Post | Main | |||||||||||||||||||||||||||||||||
| 359 | JSON-LD | Libre Lounge | ActivityPub Part 2 | In our ongoing series about ActivityPub, Chris and Serge explore the world of JSON-LD and the ActivityStreams vocabulary. | https://librelounge.org/episodes/episode-17-activitypub-part-2.html | episode | Main | 2019-04-19 | ||||||||||||||||||||||||||||||||
| 360 | JSON-LD | DIF | Orie Steel | Mental Models of JSON-LD and what a "Document Loader" really does | and terms like "dereferencing" that trip up even highly experienced senior developers that show up late to the Linked-Data party and its open-world model (complete with its own security model based on different availability assumptions). | Former Chair Orie Steele (Transmute Industries) was invited to give an "explain it to me like I'm five" session about the Document Loader his company donated... | https://www.youtube.com/watch?v=-yUbMDft5O0 | Video | Main | 2020-11-09 | ||||||||||||||||||||||||||||||
| 361 | JSON-LD | Manu Sporny | https://news.ycombinator.com/item?id=14474222 | Manu Sporny | JSON-LD and Why I Hate the Semantic Web | JSON-LD is a product of consensus. Nobody agrees on everything in there, but it all sticks together pretty well. There being a consensus on consensus is what makes the W3C, IETF, and thus the Web and the Internet work. Through all of the fits and starts, permathreads, pedantry, idealism, and deadlock, the way it brings people together to build this thing we call the Web is beautiful thing. | https://web.archive.org/web/20190219191153/https://manu.sporny.org/2014/json-ld-origins-2/ | Post | Main | 2014-01-21 | ||||||||||||||||||||||||||||||
| 362 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | What is Linked Data? | Short video introduction to Linked Data | http://www.youtube.com/watch?v=4x_xzT5eF5Q | https://i.ytimg.com/vi/4x_xzT5eF5Q/hqdefault.jpg?sqp=-oaymwEmCOADEOgC8quKqQMa8AEB-AH-BIAC6AKKAgwIABABGGUgZShlMA8=&rs=AOn4CLCvueCMZtGroF8Av7FB6w4qX4gSmA | Video | Explainer | 2012-06-17 | |||||||||||||||||||||||||||||
| 363 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | What is JSON-LD? | Short video introduction to JSON-LD | http://www.youtube.com/watch?v=vioCbTo3C-4 | https://i.ytimg.com/vi/vioCbTo3C-4/hqdefault.jpg?sqp=-oaymwEmCOADEOgC8quKqQMa8AEB-AH-BIAC6AKKAgwIABABGGUgZShlMA8=&rs=AOn4CLDVYrCk-mGtd6c_FqzZCIb9tyNIIw | Video | Explainer | 2012-06-19 | |||||||||||||||||||||||||||||
| 364 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | JSON-LD: Core Markup | An overview of some of the core markup features of JSON-LD including types, aliasing, nesting, and internationalization support | https://www.youtube.com/watch?v=UmvWk_TQ30A | https://i.ytimg.com/vi/UmvWk_TQ30A/maxresdefault.jpg | Video | Explainer | 2015-02-18 | |||||||||||||||||||||||||||||
| 365 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | JSON-LD: Compaction and Expansion | An overview of JSON-LD's compaction and expansion features and how you can use them to merge data from multiple sources | https://www.youtube.com/watch?v=Tm3fD89dqRE | https://i.ytimg.com/vi/Tm3fD89dqRE/maxresdefault.jpg | Video | Explainer | 2015-02-18 | |||||||||||||||||||||||||||||
| 366 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | Linked Data Signatures | An overview of how digital signatures can be added to Linked Data to provide verifiable statements on the Web | https://www.youtube.com/watch?v=QdUZaYeQblY | https://i.ytimg.com/vi/QdUZaYeQblY/maxresdefault.jpg | Video | Explainer | 2015-02-17 | |||||||||||||||||||||||||||||
| 367 | JSON-LD | Personal | https://json-ld.org/learn.html | Manu Sporny | Credentials on the Web | A quick introduction to verifiable credentials on the Web | https://www.youtube.com/watch?v=eWtOg3vSzxI | Video | Explainer | 2015-02-17 | ||||||||||||||||||||||||||||||
| 368 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler | World Wide Web Conference | Creating 3rd Generation Web APIs with JSON-LD and Hydra | Proceedings of the Proceedings of the 22nd International World Wide Web Conference (WWW2013), pp. 35-37. Rio de Janeiro, Brazil: ACM Press | http://m.lanthi.com/www2013-paper | Paper | Explainer | 2013-04-01 | |||||||||||||||||||||||||||||
| 369 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler, Christian Gütl | World Wide Web Conference | Model Your Application Domain, Not Your JSON Structures | Proceedings of the 4th International Workshop on RESTful Design (WS-REST 2013) at WWW2013, pp. 1415-1420. Rio de Janeiro, Brazil: ACM Press | http://m.lanthi.com/wsrest2013-paper | Paper | Explainer | 2013-04-03 | |||||||||||||||||||||||||||||
| 370 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler, Christian Gütl | Rio de Janeiro | World Wide Web Conference | Hydra: A Vocabulary for Hypermedia-Driven Web APIs | Proceedings of the 6th Workshop on Linked Data on the Web (LDOW2013) at WWW2012 | http://m.lanthi.com/ldow2013-paper | Paper | Explainer | 2013-04-11 | ||||||||||||||||||||||||||||
| 371 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler, Christian Gütl | World Wide Web Conference | On Using JSON-LD to Create Evolvable RESTful Services | Proceedings of the 3rd International Workshop on RESTful Design (WS-REST 2012) at WWW2012, pp. 25-32. Lyon, France: ACM Press | http://www.markus-lanthaler.com/research/on-using-json-ld-to-create-evolvable-restful-services.pdf | Paper | Explainer | 2012-04-26 | |||||||||||||||||||||||||||||
| 372 | JSON-LD | Personal | https://json-ld.org/learn.html | Gregg Kellogg | San Francisco, CA, USA | Social Standards Workshop 2013 | JSON-LD: JSON for the Social Web | JSON-LD JSON for the Social Web Gregg Kellogg gregg@greggkellogg.net @gkellogg Wednesday, August 7, 13 Introducing JSON-LD JSON-based syntax to express linked... | Short presentation on JSON-LD for the W3C Social Standards Workshop held in San Francisco in August 2013. | http://www.slideshare.net/gkellogg1/jsonld-json-for-the-social-web | Presentation | Presentation | 2013-08-01 | |||||||||||||||||||||||||||
| 373 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler | OR, USA | Symfony Live Portland 2013 | Building Next-Generation Web APIs with JSON-LD and Hydra | Building Next-Gen Web APIs with JSON-LD and Hydra Markus Lanthaler Why do we need a website? Of course we have a website Why do we need an API? 1995 2000 2005... | Presented at the Symfony Live Portland 2013 in Portland (Oregon), USA<br>The recording of the talk is available at http://bit.ly/sl-portland2013-video | http://slidesha.re/sl-portland2013 | Presentation | Presentation | 2013-05-29 | |||||||||||||||||||||||||||
| 374 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler | Rio de Janeiro, Brazil | World Wide Web Conference | Model Your Application Domain, Not Your JSON Structures | Model Your Application Domain, NotYour JSON Structures Markus Lanthaler Graz University ofTechnology RPC REST APIs must be hypertext-driven Got a head... | http://slidesha.re/wsrest2013-preso | Presentation | Presentation | 2013-05-14 | ||||||||||||||||||||||||||||
| 375 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler | Rio de Janeiro, Brazil | World Wide Web Conference | Hydra: A Vocabulary for Hypermedia-Driven Web APIs | Hydra AVocabulary for HypermediaAPIs Markus Lanthaler Graz University ofTechnology Why can’t Web APIs be browsed? - Layered system REST + Linked Data: a mat... | http://slidesha.re/ldow2013-preso | Presentation | Presentation | 2013-05-14 | ||||||||||||||||||||||||||||
| 376 | JSON-LD | Personal | https://json-ld.org/learn.html | Gregg Kellogg | San Francisco, CA, USA | Semantic Technology & Business Conference | JSON-LD: JSON for Linked Data | JSON-LD JSON for Linked Data Gregg Kellogg gregg@greggkellogg.net @gkellogg JSON-LD JSON for Linked Data nk ing Li Gregg ... | http://www.slideshare.net/gkellogg1/json-for-linked-data | Presentation | Presentation | 2012-05-30 | ||||||||||||||||||||||||||||
| 377 | JSON-LD | Personal | https://json-ld.org/learn.html | Markus Lanthaler | Lyon, France | JSON-LD for RESTful Services | JSON-LD for RESTful Services Markus Lanthaler Graz University of Technology Web APIs are becoming a must-have - Layered system Semaphobia!? Linked Data G... | http://slidesha.re/jsonld4rest | Presentation | Presentation | 2012-04-17 | |||||||||||||||||||||||||||||
| 378 | JSON-LD | Personal | https://json-ld.org/learn.html | Gregg Kellogg | CA, USA | NoSQL Now! | JSON-LD and MongoDB | JSON-LD and MongoDB Powering Linked Web Apps Gregg Kellogg gregg@greggkellogg.net @gkellogg JSON-LD and Mongo • JSON-LD – graph expressio... | http://www.slideshare.net/gkellogg1/jsonld-and-mongodb | Presentation | Presentation | 2012-08-19 | ||||||||||||||||||||||||||||
| 379 | JSON-LD | JSON-LD WG | W3C | JSON-LD Working Group | The Working Group maintains the JSON-LD specifications (i.e., JSON-LD 1.1, JSON-LD 1.1 API, JSON-LD 1.1 Framing) that together provide a JSON format for Linked Open Data to interoperate at web-scale, in a method which is familiar to and usable by web-focused software engineers. | The mission of the JSON-LD Working Group is to maintain the JSON-LD 1.1 specifications. | https://www.w3.org/2018/json-ld-wg/ | Working Group | Working Group | JSON-LD WG | 2018-07-15 | https://github.com/w3c/json-ld-wg | ||||||||||||||||||||||||||||
| 380 | JSON-LD | JSON-LD WG | W3C | JSON-LD 1.1 Framing Specification | JSON-LD Framing allows developers to query by example and force a specific tree layout to a JSON-LD document.<br><br>This specification describes a superset of the features defined in JSON-LD Framing 1.0 [JSON-LD10-FRAMING] and, except where noted, the algorithms described in this specification are fully compatible with documents created using the previous community standard. | https://w3c.github.io/json-ld-framing/ | Specification | Working Group | JSON-LD WG | 2023-04-12 | https://github.com/w3c/json-ld-framing | |||||||||||||||||||||||||||||
| 381 | JSON-LD | JSON-LD WG | W3C | JSON-LD 1.1 Processing Algorithms and API Specification | This specification defines a set of algorithms for programmatic transformations of JSON-LD documents. Restructuring data according to the defined transformations often dramatically simplifies its usage. Furthermore, this document proposes an Application Programming Interface (API) for developers implementing the specified algorithms. | https://w3c.github.io/json-ld-api/ | Specification | Working Group | JSON-LD WG | 2023-04-12 | https://github.com/w3c/json-ld-api | |||||||||||||||||||||||||||||
| 382 | JSON-LD | JSON-LD WG | W3C | JSON-LD 1.1 Syntax | JSON is a useful data serialization and messaging format. This specification defines JSON-LD 1.1, a JSON-based format to serialize Linked Data. The syntax is designed to easily integrate into deployed systems that already use JSON, and provides a smooth upgrade path from JSON to JSON-LD. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. | https://github.com/w3c/json-ld-syntax | Specification | Working Group | JSON-LD WG | 2023-04-12 | ||||||||||||||||||||||||||||||
| 383 | JSON-LD | JSON-LD WG | W3C | JSON-LD Best Practices | Developers share a common problem: they want a simple, but extensible way to create an API for a web service that gets the job done, doesn't design them into a corner, and allows developers to easily interact with their service without reinventing the wheel. JSON-LD [JSON-LD] has become an important solution, as it bridges the gap between formally data and more colloquial JSON interfaces used in APIs from numerous providers. This guide attempts to define certain best practices for publishing data using JSON-LD, and interacting with such services. | https://w3c.github.io/json-ld-bp/ | note | Working Group | JSON-LD WG | 2023-04-12 | ||||||||||||||||||||||||||||||
| 384 | JSON-LD | JSON-LD WG | W3C | JSON-LD Recommended Context | This is the repository for a recommended context for JSON-LD 1.1, as well as the RDFa Core Initial Context, developed and maintained by the W3C JSON-LD Working Group. Most of the major resources in this repository are redirected from W3C URI-s that have been in use by the community for a while. These are as follows: | https://w3c.github.io/json-ld-rc/context.jsonld | note | Working Group | JSON-LD WG | 2020-05-07 | https://github.com/w3c/json-ld-rc | |||||||||||||||||||||||||||||
| 385 | JSON-LD | JSON-LD WG | JSON-LD 1.1 Framing Specification | This specification describes a superset of the features defined in [JSON-LD10-FRAMING] and, except where noted, the algorithms described in this specification are fully compatible with documents created using the previous community standard. | https://w3c.github.io/json-ld-framing/ | Specification | Working Group | 2023-04-12 | https://github.com/w3c/json-ld-framing | |||||||||||||||||||||||||||||||
| 386 | JSON-LD | JSON-LD WG | JSON-LD 1.1 Processing Algorithms and API Specification | This specification defines a set of algorithms for programmatic transformations of JSON-LD documents. Restructuring data according to the defined transformations often dramatically simplifies its usage. Furthermore, this document proposes an Application Programming Interface (API) for developers implementing the specified algorithms. | https://w3c.github.io/json-ld-api/ | Specification | Working Group | 2023-04-12 | https://github.com/w3c/json-ld-api | |||||||||||||||||||||||||||||||
| 387 | JSON-LD | JSON-LD WG | JSON-LD 1.1 Specification | This specification describes a superset of the features defined in JSON-LD 1.0 [JSON-LD10] and, except where noted, documents created using the 1.0 version of this specification remain compatible with JSON-LD 1.1 | https://w3c.github.io/json-ld-syntax/ | Specification | Working Group | 2023-04-12 | https://github.com/w3c/json-ld-syntax | |||||||||||||||||||||||||||||||
| 388 | JSON-LD | JSON-LD WG | JSON-LD 1.1 Best Practices Note | Developers share a common problem: they want a simple, but extensible way to create an API for a web service that gets the job done, doesn't design them into a corner, and allows developers to easily interact with their service without reinventing the wheel. JSON-LD [JSON-LD] has become an important solution, as it bridges the gap between formally data and more colloquial JSON interfaces used in APIs from numerous providers. This guide attempts to define certain best practices for publishing data using JSON-LD, and interacting with such services. | https://w3c.github.io/json-ld-bp/ | note | Working Group | 2023-04-12 | https://github.com/w3c/json-ld-bp | |||||||||||||||||||||||||||||||
| 389 | JSON-LD | JSON-LD WG | JSON-LD Recommended Context | https://w3c.github.io/json-ld-rc/context.jsonld | Code | Working Group | 2023-04-12 | https://github.com/w3c/json-ld-rc | ||||||||||||||||||||||||||||||||
| 390 | JSON-LD | JSON-LD WG | Teleconference minutes - text and audio logs | JSON-LD Teleconference Minutes | https://github.com/json-ld/minutes | page | Working Group | 2023-05-17 | ||||||||||||||||||||||||||||||||
| 391 | JSON-LD | JSON-LD WG | Charter for JSON-LD WG | Since its original publication in 2014 by the RDF 1.1 Working Group, JSON-LD 1.0 has become an essential format for describing structured data on the World Wide Web. It is estimated to be used by between 10% and 18.2% of all websites. This is due largely to its adoption as a recommended format by schema.org. It has been adopted by several Recommendations including those from the Social Web, Web Annotation, and Linked Data Platform Working Groups, and current Working Groups have expressed interest in alignment of their specifications, such as the Publishing and Web of Things Working Groups. It has provided a much-needed bridge between communities that need rich semantics, and those that desire an intuitive and easily usable format (see separate wiki page for more details). | https://www.w3.org/2018/03/jsonld-wg-charter.html | page | Working Group | 2018-06-07 | ||||||||||||||||||||||||||||||||
| 392 | JSON-LD | Personal | Daniel Stainback | piprate/json-gold | This library is an implementation of the JSON-LD 1.1 specification in Go. It supports both URDNA2015 and URGNA2012 RDF dataset normalisation algorithms. | - JSON-goLD Documentations Travis CI results GoCover.io | https://github.com/piprate/json-gold | Code | Development | 2021-01-11 | ||||||||||||||||||||||||||||||
| 393 | JSON-LD | Personal | Jay Holtslander | Structured Data / JSON-LD | Collection of structured data snippets in Google preferred JSON-LD format. [codepen.io/collection/DNvPJE/](https://codepen.io/collection/DNvPJE/) | Collection of structured data snippets in Google preferred JSON-LD format. - GitHub - JayHoltslander/Structured-Data-JSON-LD: Collection of structured data snippets in Google preferred JSON-LD format. | https://github.com/JayHoltslander/Structured-Data-JSON-LD | Code | Development | 2022-08-16 | ||||||||||||||||||||||||||||||
| 394 | JSON-LD | CodeMeta | codemeta/codemeta | CodeMeta contributors are creating a minimal metadata schema for science software and code, in JSON and XML. The goal of CodeMeta is to create a concept vocabulary that can be used to standardize the exchange of software metadata across repositories and organizations. CodeMeta started by comparing the software metadata used across multiple repositories, which resulted in the CodeMeta Metadata Crosswalk. That crosswalk was then used to generate a set of software metadata concepts, which were arranged into a JSON-LD context for serialization. | Minimal metadata schemas for science software and code, in JSON-LD - GitHub - codemeta/codemeta: Minimal metadata schemas for science software and code, in JSON-LD | https://github.com/codemeta/codemeta | Code | Development | 2023-04-26 | |||||||||||||||||||||||||||||||
| 395 | JSON-LD | Codeship | https://json-ld.org/learn.html | Benjamin Young | JSON-LD: Building Meaningful Data APIs | Meet JSON-LD! JSON-LD stands for JSON for Linked Data." It's a specification for encoding contextualized meaning into otherwise meaningless JSON documents. " | http://blog.codeship.com/json-ld-building-meaningful-data-apis/ | Post | Development | 2016-05-17 | ||||||||||||||||||||||||||||||
| 396 | JSON-LD | Personal | Daniel Stainback | Extremely simple JSON-LD Generator | https://github.com/Torann/json-ld | Code | Development | 2021-02-22 | ||||||||||||||||||||||||||||||||
| 397 | JSON-LD | Digital Bazaar | JSON-LD command line interface tool | This module provides a command line tool jsonld to manipulate JSON-LD data. It is written in JavaScript for Node.js and uses the jsonld.js and jsonld-request libraries. Inputs can be from stdin, URLs, or files. | https://github.com/digitalbazaar/jsonld-cli | Code | Development | 2022-08-01 | ||||||||||||||||||||||||||||||||
| 398 | JSON-LD | Digital Bazaar | JSON-LD processor written in Python | This library is an implementation of the JSON-LD specification in Python | https://github.com/digitalbazaar/pyld | Code | Development | 2020-08-07 | ||||||||||||||||||||||||||||||||
| 399 | JSON-LD | Digital Bazaar | A JSON-LD Processor and API implementation in JavaScript | This library is an implementation of the JSON-LD specification in JavaScript. | https://github.com/digitalbazaar/jsonld.js | Code | Development | 2023-05-20 | ||||||||||||||||||||||||||||||||
| 400 | JSON-LD | Digital Bazaar | PHP implementation of a JSON-LD Processor and API | This library is an implementation of the JSON-LD specification in PHP | https://github.com/digitalbazaar/php-json-ld | Code | Development | 2019-05-17 | ||||||||||||||||||||||||||||||||
| 401 | JSON-LD | Digital Bazaar | An implementation of the Linked Data Signatures specification for JSON-LD. Works in the browser and Node.js | An implementation of the Linked Data Signatures specification for JSON-LD, for Node.js and browsers. | https://github.com/digitalbazaar/jsonld-signatures | Code | Development | 2023-05-15 | ||||||||||||||||||||||||||||||||
| 402 | JSON-LD | Digital Bazaar | LIbrary to load JSON-LD from stdin, URLs, or files | This JavaScript Node.js library is used to read data from stdin, URLs, or files and convert to JSON-LD via jsonld.js. It can process JSON-LD in JSON and RDFa in HTML and output JSON-LD. | https://github.com/digitalbazaar/jsonld-request | Code | Development | 2022-08-01 | ||||||||||||||||||||||||||||||||
| 403 | JSON-LD | Digital Bazaar | JSON patch for JSON-LD | This library provides an API for applying JSON patches to JSON-LD documents. JSON patches may be represented in JSON-LD by using hte will be interpreted as JSON-LD using the JSON-LD Patch @context. | https://github.com/digitalbazaar/jsonld-patch | Code | Development | 2021-02-26 | ||||||||||||||||||||||||||||||||
| 404 | JSON-LD | Digital Bazaar | Cryptographic Key Pair Library for Linked Data (crypto-ld) | A Javascript library for generating and performing common operations on Linked Data cryptographic key pairs. | https://github.com/digitalbazaar/crypto-ld | Code | Development | 2022-06-02 | ||||||||||||||||||||||||||||||||
| 405 | WebAuthN | Microsoft | Pamela Dingle | Why WebAuthn will change the world | A little over a month ago, W3C WebAuthn became a real internet specification. Most of you don’t know what WebAuthn is yet, but many of you will feel the impact in short order. In fact, I will go so far as to say that WebAuthn may change how we all authenticate to the resources we use every day. <br><br>We live in a world where the best parts of our individual local hardware and software collection are rarely leveraged to make cloud security decisions. This is because there has never been a vendor-agnostic and privacy-preserving way for cloud resources to interact with individual hardware configurations in any generic way. Until now! <br><br>With WebAuthn, any web entity can call a simple Javascript API and ask for a cryptographically secure credential. What happens next is pretty cool – the world’s browsers have worked with the world’s operating system makers and the world’s hardware manufacturers, so that when a website asks for a credential, the browsers work with the underlying platform to securely locate compliant local hardware and talk to it! | https://techcommunity.microsoft.com/t5/identity-standards-blog/why-webauthn-will-change-the-world/ba-p/482286 | Post | Main | 2019-04-19 | |||||||||||||||||||||||||||||||
| 406 | WebAuthN | ZDNet | W3C finalizes Web Authentication (WebAuthn) standard - ZDNet | WebAuthn allows users to register and authenticate on websites or mobile apps using an "authenticator" instead of a password.<br><br>The "authenticator" can be a hardware security key that the user has connected to his computer or a biometric ID that can be acquired from the PC or smartphone's sensors --such as fingerprints, face scans, iris scans, and others. | https://www.zdnet.com/article/w3c-finalizes-web-authentication-webauthn-standard/ | Post | Main | 2019-03-04 | ||||||||||||||||||||||||||||||||
| 407 | WebAuthN | Microsoft | All about FIDO2, CTAP2 and WebAuthn | This is a great week to be working in Identity Standards, as we at Microsoft celebrate the release of our first ever WebAuthn Relying Party. This one relying party enables standards-based passwordless authentication at Xbox, Skype, Outlook.com and more. But what are the actual pieces of the puzzle and how do they fit? Read on for the big picture of how the W3C WebAuthn and FIDO2 CTAP2 specifications interact. We will start with the industry standards perspective, and then at the end we will summarize how Microsoft implements the various roles. <br><br>To understand how FIDO2 authenticators work, you need knowledge of two specifications in two different standards bodies. The WebAuthentication (aka WebAuthn) spec lives at W3C (where the browser makers meet) while the Client-to-Authenticator (aka CTAP2) spec lives at the FIDO Alliance (where hardware and platform folks have joined to solve the problem of Fast IDentity Online). | https://techcommunity.microsoft.com/t5/Identity-Standards-Blog/All-about-FIDO2-CTAP2-and-WebAuthn/ba-p/288910 | https://techcommunity.microsoft.com/t5/image/serverpage/image-id/60283iDDAE6B0B53A24427/image-size/original?v=v2&px=-1 | Post | Main | 2018-11-20 | |||||||||||||||||||||||||||||||
| 408 | WebAuthN | Microsoft | To Understand WebAuthn, Read CredMan | The holidays are well and truly over, time to get serious - now is the perfect time to read specifications! If you are planning to read the WebAuthn specification, you can ease into the terminology in a simple way - take a cruise through the W3C Credential Management (aka CredMan) specification first. CredMan sets up the object model for the Credential object model that WebAuthn's PublicKeyCredential extends. This post will be an overview of the CredMan spec, geared for folks who want to call the API as clients, not for those few and proud who are tasked with implementation of the API within a user agent. | https://techcommunity.microsoft.com/t5/identity-standards-blog/to-understand-webauthn-read-credman/ba-p/339652 | https://techcommunity.microsoft.com/t5/image/serverpage/image-id/78172i3FDF4848680EABE1/image-size/original?v=v2&px=-1 | Post | Main | 2019-02-15 | |||||||||||||||||||||||||||||||
| 409 | WebAuthN | GitHub | Lucas Garron | GitHub supports Web Authentication (WebAuthn) for security keys | GitHub now supports Web Authentication (WebAuthn) for security keys—the new standard for secure authentication on the web. Starting today, you can use security keys for two-factor authentication on GitHub with even more browsers and devices. And, since many browsers are actively working on WebAuthn features, we’re excited about the potential for strong and easy-to-use authentication options for the entire GitHub community in the future. | The WebAuthn standard for security keys is making authentication as easy as possible. Now you can use security keys for second-factor authentication on GitHub with many more browsers and devices. | https://github.blog/2019-08-21-github-supports-webauthn-for-security-keys/ | https://github.blog/wp-content/uploads/2019/08/Screen-Shot-2019-08-21-at-11.34.02-copy.png?fit=2400%2C1260 | Post | Main | 2019-08-21 | |||||||||||||||||||||||||||||
| 410 | WebAuthN | Fido Alliance | WebAuthn Workshop | https://slides.com/fidoalliance/webauthn-overview | https://media.slid.es/thumbnails/0d31fdc30b303d4443a65dd550767eee/thumb.jpg?1538300008 | Presentation | Main | 2018-06-07 | ||||||||||||||||||||||||||||||||
| 411 | WebAuthN | Personal | Ackermann Yuri | WebAuthn Awesome Awesome | A curated list of awesome WebAuthn/FIDO2 resources | https://github.com/herrjemand/awesome-webauthn | list | Main | 2023-04-06 | |||||||||||||||||||||||||||||||
| 412 | WebAuthN | WebAuthN Guide | Guide to Web Authentication | Passwords have an ever-growing list of problems associated with them, both for users and developers. Users have to worry about passwords being stolen by phishing tools, or their passwords being leaked online if websites they have accounts with are compromised. They have to worry about creating and remembering passwords without dedicated password management tools. Developers have to worry about all the complications of passing passwords through systems and safely storing them in databases. | An introduction to Web Authentication (WebAuthn), the new API that can replace passwords with strong authentication. | https://webauthn.guide | page | Main | ||||||||||||||||||||||||||||||||
| 413 | WebAuthN | Auth0 | Web Authentication (WebAuthn) Credential and Login Demo | Web Authentication is a W3C recommendation for defining an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.<br><br>Web Authentication works hand in hand with other industry standards such as Credential Management Level 1 and FIDO 2.0 Client to Authenticator Protocol 2.<br><br>Auth0 allows you to quickly setup Multi-Factor Authentication with WebAuthn | Try the Web Authentication demo to register a credential and login with biometrics. WebAuthn spec enables public key-based credentials for securely authenticating users using hardware authenticators. | https://webauthn.me | page | Main | ||||||||||||||||||||||||||||||||
| 414 | WebAuthN | FIDO Alliance | FIDO2: WebAuthn & CTAP | The FIDO Alliance developed FIDO Authentication standards based on public key cryptography for authentication that is more secure than passwords and SMS OTPs, simpler for consumers to use, and easier for service providers to deploy and manage. FIDO Authentication enables password-only logins to be replaced with secure and fast login experiences across websites and apps. | https://fidoalliance.org/fido2/ | page | FIDO Alliance | |||||||||||||||||||||||||||||||||
| 415 | WebAuthN | FIDO Alliance | FIDO2: Web Authentication (WebAuthn) | Web Authentication (WebAuthn), a core component of FIDO Alliance’s FIDO2 set of specifications, is a web-based API that allows websites to update their login pages to add FIDO-based authentication on supported browsers and platforms. FIDO2 enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments. | https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/ | page | FIDO Alliance | |||||||||||||||||||||||||||||||||
| 416 | WebAuthN | WebAuthNWG | https://w3c.github.io/webauthn/ | W3C | Web Authentication Working Group | The mission of the Web Authentication Working Group, in the Security Activity is to define a client-side API providing strong authentication functionality to Web Applications. | https://www.w3.org/Webauthn/ | Working Group | Working Group | Web Authentication Working Group | 2016-02-08 | https://github.com/w3c/webauthn | https://www.w3.org/blog/webauthn/ | |||||||||||||||||||||||||||
| 417 | WebAuthN | WebAuthNWG | W3C | Web Authentication: An API for accessing Public Key Credentials | This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality. | https://w3c.github.io/webauthn/ | https://w3c.github.io/webauthn/images/webauthn-registration-flow-01.svg | Specification | Working Group | Web Authentication Working Group | 2023-05-17 | https://github.com/w3c/webauthn | ||||||||||||||||||||||||||||
| 418 | WebAuthN | WebAuthNWG | Samuel Weiler | Web Authentication Working Group Charter | The Web Authentication Working Group will develop recommendation-track specifications defining an API, as well as signature and attestation formats which provide an asymmetric cryptography-based foundation for authentication of users to Web Applications.<br><br>Overall goals include obviating the use of shared secrets, i.e. passwords, as authentication credentials, facilitating multi-factor authentication support as well as hardware-based key storage while respecting the Same Origin Policy (SOP) by default and allowing for explicit, constrained SOP relaxation. | https://www.w3.org/2019/10/webauthn-wg-charter.html | Post | Working Group | 2019-10-15 | |||||||||||||||||||||||||||||||
| 419 | WebAuthN | Stranger Labs | webauthn - npmjs.com | WebAuthn is a W3C standard that enables web developers to replace passwords in their applications with FIDO authentication. This repository implements a NPM package for use in Node.js services. This package is in active development and not yet ready for production use. You can use it to kick the tires on WebAuthn. Please file issues to ask questions or provide feedback. | W3C Web Authentication API Relying Party for Node.js and Express. Latest version: 0.2.0, last published: 4 years ago. Start using webauthn in your project by running `npm i webauthn`. There are no other projects in the npm registry using webauthn. | https://www.npmjs.com/package/webauthn | Code | Development | 2019-11-25 | |||||||||||||||||||||||||||||||
| 420 | WebAuthN | WebAuthN.io | WebAuthn (FIDO2) server library written in Go | This library is meant to handle Web Authentication for Go apps that wish to implement a passwordless solution for users. While the specification is currently in Candidate Recommendation, this library conforms as much as possible to the guidelines and implementation procedures outlined by the document. | Demonstration of the WebAuthn specification. | https://webauthn.io/ | page | Development | https://github.com/duo-labs/webauthn | |||||||||||||||||||||||||||||||
| 421 | WebAuthN | What is WebAuthn? What is FIDO2? | The FIDO2 / WebAuthn allows you to create and use strong, attested public key based credentials for the purpose of authenticating users. The API supports the use of BLE, NFC, and USB roaming authenticators (security keys) as well as a platform authenticator, which allows the user to authenticate using their fingerprint or screenlock. | Learn how to build a website with a simple reauthentication functionality that uses a fingerprint sensor. | https://codelabs.developers.google.com/codelabs/webauthn-reauth/#0 | https://developers.google.com/static/codelabs/webauthn-reauth/img/260aab9f1a2587a7.png | Post | Development | 2022-05-12 | |||||||||||||||||||||||||||||||
| 422 | WebAuthN | Enabling Strong Authentication with WebAuthn | The Web Authentication API gives Web applications user-agent-mediated access to authenticators – which are often hardware tokens accessed over USB/BLE/NFC or modules built directly into the platform – for the purposes of generating and challenging application-scoped (eTLD+k) public-key credentials. | Chrome 67 beta introduces the Web Authentication (WebAuthn) API, which allows browsers to interact with and manage public-key based credentials. This enables strong authentication using removable security keys and built-in platform authenticators such as fingerprint scanners. | https://developers.google.com/web/updates/2018/05/webauthn | Post | Development | 05-2018 | ||||||||||||||||||||||||||||||||
| 423 | WebAuthN | Mozilla | Web Authentication API | The Web Authentication API (WebAuthn) is an extension of the Credential Management API that enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication (MFA) without SMS texts. | https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API | page | Development | |||||||||||||||||||||||||||||||||
| 424 | Blockcerts | Learning Machine | Digital Identity | A framework for organizing the categories of digital identity and an analysis of where disruptive innovation is most likely to succeed. | https://www.learningmachine.com/digital-identity/ | page | Learning Machine | 2018-10-06 | ||||||||||||||||||||||||||||||||
| 425 | Blockcerts | Learning Machine | Learning Machine | Get a complete system to issue digital credentials in a blockchain-secured format that is easily shareable and instantly verifiable anywhere in the world. | https://www.learningmachine.com/ | https://www.learningmachine.com/wp-content/uploads/2019/06/mobile-cert-min.png | company | Learning Machine | 2016 | |||||||||||||||||||||||||||||||
| 426 | Blockcerts | Personal | Natalie Smolenski | Natalie Smolenski - Author, Speaker | Natalie Smolenski is an anthropologist leading business development for blockchain technology firm Learning Machine. She writes and speaks about identity, tech, and government. | https://www.nataliesmolenski.com/ | blog | Learning Machine | ||||||||||||||||||||||||||||||||
| 427 | Blockcerts | Learning Machine | Academic Credentialing and the Blockchain | Hello everyone. My name is Chris Jagers. I’m the CEO of Learning Machine, the software company that has been working with MIT over the last year to develop an open standard for blockchain certificates. I’ll be giving a short presentation about blockchain-based academic credentials, followed by a discussion with our panel and with all of you. | https://www.learningmachine.com/academic-credentialing-blockchain/ | page | Learning Machine | 2016-10-28 | ||||||||||||||||||||||||||||||||
| 428 | Blockcerts | Hyland Credentials | Future Proof | Learning Machine is proud to announce that we have won Phase-1 funding for our response to the open call “Preventing Forgery & Counterfeiting of Certificates and Licenses through the use of Blockchain and Distributed Ledger Technology.” [...] The open-source reference implementation, targeted for 2020, will include:<br>- Updating the Blockcerts schema to a Verifiable Credentials-based format<br>- Updating the Blockcerts signature/verification scheme to conform to the latest JSON-LD signature suite format<br>- Updating Blockcerts credential issuance and verification<br>- Incorporating a cost-efficient DID method for issuers | https://www.hylandcredentials.com/future-proof | https://www.learningmachine.com/wp-content/uploads/2019/07/vc.png | page | Learning Machine | 2017-07 | |||||||||||||||||||||||||||||||
| 429 | Blockcerts | Blockcerts | Blockcerts | Blockcerts | open standard for issuing and verifying blockchain-based official records; The project offers open-source libraries, tools, and mobile apps. MIT has [issued](https://www.insidehighered.com/news/2017/10/19/mit-introduces-digital-diplomas) digital certificates based on this standard. | Build apps that issue and verify blockchain-based credentials for academic credentials, professional certifications, workforce development, and civic records. | https://www.blockcerts.org/ | project | Blockcerts | 2016 | https://github.com/blockchain-certificates | https://twitter.com/blockcerts | http://community.blockcerts.org/ | |||||||||||||||||||||||||||
| 430 | Blockcerts | Blockcerts | Introduction | Blockcerts is an open standard for building apps that issue and verify blockchain-based official records. These may include certificates for civic records, academic credentials, professional licenses, workforce development, and more.<br><br>Blockcerts consists of open-source libraries, tools, and mobile apps enabling a decentralized, standards-based, recipient-centric ecosystem, enabling trustless verification through blockchain technologies.<br><br>Blockcerts uses and encourages consolidation on open standards. Blockcerts is committed to self-sovereign identity of all participants, and enabling recipient control of their claims through easy-to-use tools such as the certificate wallet (mobile app). Blockcerts is also committed to availability of credentials, without single points of failure. | Build apps that issue and verify blockchain-based credentials for academic credentials, professional certifications, workforce development, and civic records. | https://www.blockcerts.org/guide/ | https://www.blockcerts.org/assets/img/pictures/blockcerts.png | page | Blockcerts | |||||||||||||||||||||||||||||||
| 431 | Blockcerts | MIT Media Lab | Blockcerts — An Open Infrastructure for Academic Credentials on the Blockchain | What would an academic degree look like if it was designed today? Or a professional certificate? These are questions we have been working on over the last year, and we are excited to announce the… | https://medium.com/mit-media-lab/blockcerts-an-open-infrastructure-for-academic-credentials-on-the-blockchain-899a6b880b2f | https://miro.medium.com/v2/resize:fit:1200/1*zrTpMx8dQKK_XAJLtLdOGg.png | Post | Blockcerts | 2016-10-25 | |||||||||||||||||||||||||||||||
| 432 | Blockcerts | Learning Machine | Natalie Smolenski | Top 10 Reasons to Use Blockcerts | The open standard for issuing blockchain-based records is your easiest bet for creating records that remain verifiable for a lifetime. | With more blockchain credentialing solutions popping up every week, it can be difficult to navigate the landscape of offerings. How do you decide which blockchain credentialing framework to use? One… | https://medium.com/learning-machine-blog/top-10-reasons-to-use-blockcerts-ec7d29f2712c | Post | Blockcerts | 2018-05-19 | ||||||||||||||||||||||||||||||
| 433 | Blockcerts | SSIMeetup | https://www.slideshare.net/SSIMeetup/blockcerts-the-open-standard-for-blockchain-credentials | Blockcerts: The Open Standard for Blockchain Credentials | <center><iframe src="//www.slideshare.net/slideshow/embed_code/key/rVC25i8FzeTPiw" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen</iframe</center> | Anthony Ronning, an engineer behind Blockcerts and backend dev at Learning Machine and Daniel Paramo, co-founder of swys and advisor at Xertify, explains how Blockcerts started, deep dive on how Blockcerts work, which institutions are implementing this solution and what companies have made a solution for the adoption of this standard. We will review the current Blockcerts roadmap and their pros and cons. What considerations do we need to take when developing a solution around Blockcerts? | https://ssimeetup.org/blockcerts-open-standard-blockchain-credentials-daniel-paramo-anthony-ronning-webinar-39/ | Presentation | Blockcerts | 2019-10-12 | ||||||||||||||||||||||||||||||
| 434 | Blockcerts | WebofTrustInfo | rwot5-boston | A Decentralized Approach to Blockcerts Credential Revocation | The initial release of the Blockcerts standard and reference implementation described only one revocation mechanism, the issuer-hosted revocation list approach also used by Open Badges. This has known limitations, including: centralization, single point of failure, and inability for a recipient to revoke. Other approaches to revocation were considered, but none were technically or economically feasible at the time given the project goals, including Bitcoin blockchain anchoring, low overhead, and minimal cost. | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/blockcerts-revocation.md | Paper | Blockcerts | 2018-02-09 | |||||||||||||||||||||||||||||||
| 435 | Blockcerts | WebofTrustInfo | https://community.blockcerts.org/t/blockcerts-v3-proposal-verifiable-credentials-decentralized-identifiers/2221 | rwot9-prague | Blockcerts V3 Proposal - Verifiable Credentials & Decentralized Identifiers | As the standards around Verifable Credentials are starting to take form, different favors of "verifiable credentials-like" data structures need to make necessary changes to leverage on the rulesets outlined and constantly reviewed by knowledgeable communities such as the W3C. The purpose of this paper is to identify all of the changes needed for Blockcerts to comply with the Verifiable Credentials (VCs) and Decentralized Identifers (DIDs) standards and to expand upon the additional benefits of using a blockchain in combination with Verifiable Credentials. This paper is meant to act as an explainer in which a formal specification can be created. This paper proposes multiple implementation options for several properties. The intention is that we can engage the Blockcerts / Verifiable Credential communities and see what fts best. | Some of you may already know and/or have been following along. Over the last few months, since Rebooting the Web of Trust 9, we have been coming up with drafts and proposals for Blockcerts V3 for the al… | https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.pdf | Paper | Blockcerts | 2019-12-19 | https://github.com/blockchain-certificates/cert-issuer/tree/v3 | https://community.blockcerts.org/t/blockcerts-v3-proposal-verifiable-credentials-decentralized-identifiers/2221 | |||||||||||||||||||||||||||
| 436 | Blockcerts | Learning Machine | Badges and Blockcerts | In education and workforce development, it’s important to understand the differences between digital credential formats and how to combine them for greatest impact [...]<br><br>2011 saw the birth of Open Badges, which digitally and visually convey the achievement of a specific skill. Similar to the Scouts movement, which uses a small fabric symbol to represent specific achievements, digital badges were designed to convey a singular achievement through a digital image and a hosted set of data. Initially spearheaded by the Mozilla Foundation, the Open Badges standard is now maintained by the IMS Global Learning Consortium, ensuring interoperability between platforms. [...]<br><br>In response to the desire for high-stakes credentials in a digital format, the development of Blockcerts began in 2015 as part of a project by the MIT Media Lab. | https://www.learningmachine.com/badges-and-blockcerts/ | https://www.learningmachine.com/wp-content/uploads/2019/01/Screen-Shot-2019-01-29-at-9.54.40-AM.png | page | Open Badges | 2018-12-13 | |||||||||||||||||||||||||||||||
| 437 | Blockcerts | WebofTrustInfo | Open Badges | rwot6-santabarbera | Open Badges are Verifable Credentials | The Blockcerts Open Badges Draft Extension introduced a verifcation method based on those used by Verifable Credentials for the specifc use case of blockchain-anchored credentials. This paper expands that work and proposes a new option that can reside alongside existing Open Badges verifcation methods. | https://nbviewer.jupyter.org/github/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/open-badges-are-verifiable-credentials.pdf | Paper | Open Badges | 2018-06-22 | ||||||||||||||||||||||||||||||
| 438 | Blockcerts | Draftin | Open Badges | OPEN BADGES ON THE BLOCKCHAIN | This document gives an overview of the status, interesting companies and people regarding Verifiable Open Badges on the Blockchain. | https://draftin.com/documents/1138961?token=hQ5q0mCHizZum8-pkDFYUZr4YFYOWMN01BPT-5uX00hAaGxYOAlgAlhyenat76hjNpTCs-CMWPI38KWn_omp0Oc | Paper | Open Badges | 2019-07-19 | |||||||||||||||||||||||||||||||
| 439 | Blockcerts | FSMB | Healthcare and Digital Credentials: Technical, Legal, and Regulatory Considerations | Credentials expressed through a trusted identity framework can be accorded a higher value within a social interaction due to the underlying assumption that someone within the system is managing the creation and transfer of these credentials. Within any high functioning identity framework specifications, rules, and agreements based in both technological capacity and social need are necessary to ensure that the level of trustworthiness required by participants in the identity system and the community relying on the services offered by the identity system is met. | https://www.fsmb.org/siteassets/digital-credentials/digital-credentials-report-june-2019.pdf | Report | Literature | 2019-06 | ||||||||||||||||||||||||||||||||
| 440 | Blockcerts | arxiv | Marco Baldi, Franco Chiaraluce, Migelan Kodra and Luca Spalazzi | Open Badges | Security analysis of a blockchain-based protocol forthe certification of academic credentials | Abstract—We consider a blockchain-based protocol forthe certification of academic credentials named Blockcerts,which is currently used worldwide for validating digitalcertificates of competence compliant with the Open Badgesstandard. We study the certification steps that are per-formed by the Blockcerts protocol to validate a certificate,and find that they are vulnerable to a certain typeof impersonation attacks. More in detail, authenticationof the issuing institution is performed by retrieving anunauthenticated issuer profile online, and comparing somedata reported there with those included in the issuedcertificate. We show that, by fabricating a fake issuerprofile and generating a suitably altered certificate, anattacker is able to impersonate a legitimate issuer andcan produce certificates that cannot be distinguished fromoriginals by the Blockcerts validation procedure. We alsopropose some possible countermeasures against an attackof this type, which require the use of a classic public keyinfrastructure or a decentralized identity system integratedwith the Blockcerts protocol. | https://arxiv.org/pdf/1910.04622.pdf | Paper | Literature | 2019-10-11 | ||||||||||||||||||||||||||||||
| 441 | Blockcerts | Bitcoin.com | Jamie Redman | MIT Launches Blockcerts Certification Using Bitcoin | The MIT Media Lab project has already deployed a few instances of blockchain-based digital certificate verification. In October of 2015, the group issued certificates to Media Lab alumni who attended the Lab’s 30th anniversary. The organization Learning Machine also issued HR certificates to employees. MIT’s Global Entrepreneurship Bootcamp workshop in Seoul, South Korea in March 2016 published digital verification using the system. Lastly, Laboratorio para la Ciudad issued digital certificates to workshop participants in Mexico City in September 2015. | Back in June MIT Media Lab tested certification authentication using the Bitcoin blockchain. After working on research and development for over a year, the | https://news.bitcoin.com/mit-blockcerts-certification-bitcoin/ | https://static.news.bitcoin.com/wp-content/uploads/2016/10/MIT-Launches-Blockcerts-Certification-Using-Bitcoin.jpg | Post | Adoption | 2016-10-28 | |||||||||||||||||||||||||||||
| 442 | Blockcerts | InsideHighered | Lindsay McKenzie | MIT Introduces Digital Diplomas | The Massachusetts Institute of Technology is offering some students the option to be awarded tamper-free digital degree certificates when they graduate, in partnership with Learning Machine. Selected students can now choose to download a digital version of their degree certificate to their smartphones when they graduate, in addition to receiving a paper diploma. | Some of the technology institute’s graduates can now choose to receive secure virtual credentials protected by block-chain technology. | https://www.insidehighered.com/news/2017/10/19/mit-introduces-digital-diplomas | https://www.insidehighered.com/sites/default/files/media/blockcerts.jpg | Post | Adoption | 2017-10-19 | |||||||||||||||||||||||||||||
| 443 | Blockcerts | CWX | CXC (Carribean) Pilots E-Certificates on the Blockchain | During the Blockcerts pilot, some 24, 000 candidates who sat the 2018 May/June examinations and for whom CXC has e-mail addresses, will receive credentials to access their e-certificates. The candidates will also receive the traditional paper-based certificate. | https://www.cxc.org/cxc-pilots-e-certificates-on-the-blockchain/ | Post | Adoption | 2018-10-29 | ||||||||||||||||||||||||||||||||
| 444 | Blockcerts | Learning Machine | Pluggable foundation blocks for building distributed apps. | When we first started building Exceptionless we found a lack of great solutions (that's not to say there isn't great solutions out there) for many key pieces to building scalable distributed applications while keeping the development experience simple. Here are a few examples of why we built and use Foundatio: | https://github.com/learningmachine/Foundatio | Code | Development | 2016-03-18 | ||||||||||||||||||||||||||||||||
| 445 | Blockcerts | Blockcerts | JSON-LD processor written in Python | This library is an implementation of the JSON-LD specification in Python | https://github.com/blockchain-certificates/pyld | Code | Development | 2017-10-24 | ||||||||||||||||||||||||||||||||
| 446 | Blockcerts | Blockcerts | blockchain-certificates/wallet-test-resources | These are resources used to test implementations of the evolving blockcerts certificate standard and issuer conventions. | https://github.com/blockchain-certificates/wallet-test-resources | Code | Development | 2018-01-17 | ||||||||||||||||||||||||||||||||
| 447 | Blockcerts | Blockcerts | Issues Blockcerts using either the Bitcoin or Ethereum blockchain | The cert-issuer project issues blockchain certificates by creating a transaction from the issuing institution to the recipient on the Bitcoin or Ethereum blockchains. That transaction includes the hash of the certificate itself | https://github.com/blockchain-certificates/cert-issuer | Code | Development; Issuing | 2023-05-26 | ||||||||||||||||||||||||||||||||
| 448 | Blockcerts | Blockcerts | Open Badges | Command line tools for designing certificate templates and instantiating a certificate batch | Blockcerts V3 is now based off W3C Verifiable Credentials specification and does not follow Open Badges V2 nomenclature anymore. To understand the differences between v2 and v3, please refer to the docs. You may also have a look at the JSONLD and JSON-SCHEMA document | https://github.com/blockchain-certificates/cert-tools | Code | Development; Issuing | 2022-04-08 | |||||||||||||||||||||||||||||||
| 449 | Blockcerts | Blockcerts | cert-core | This python library contains common Blockcerts models and accessors used by other Blockcerts python libraries. | https://github.com/blockchain-certificates/cert-core | Code | Development; Issuing | 2022-07-12 | ||||||||||||||||||||||||||||||||
| 450 | Blockcerts | Blockcerts | Example of baking a blockcert into an Open Badge | The cert-issuer project issues blockchain certificates by creating a transaction from the issuing institution to the recipient on the Bitcoin or Ethereum blockchains. That transaction includes the hash of the certificate itself. | https://github.com/blockchain-certificates/obi-baking | Code | Development; Demo | 2017-07-13 | ||||||||||||||||||||||||||||||||
| 451 | Blockcerts | Blockcerts | PoC for Blockcerts with Status List 2021 spec | https://github.com/blockchain-certificates/rl-blockcerts-poc | Code | Development; Demo | 2023-03-30 | |||||||||||||||||||||||||||||||||
| 452 | Blockcerts | Learning Machine | learningmachine/polymer-redux | An example use-case to showcase the state/view abstraction in Polymer 3, LitElement and Redux context | https://github.com/learningmachine/polymer-redux | Code | Development; Demo | 2018-09-28 | ||||||||||||||||||||||||||||||||
| 453 | Blockcerts | Blockcerts | cert-schema | Blockchain Certificate schemas implement those of Verifiable Credentials. As with Verifiable Credentials, we've provided both a JSON-LD context and JSON schema. The purpose of the JSON-LD context is to map types to Internationalized Resource Identifiers (IRIs), providing semantic context for data. The JSON Schema is used for syntactic validation. | https://github.com/blockchain-certificates/cert-schema | Code | Development; Verifiable Credentials | 2023-05-17 | ||||||||||||||||||||||||||||||||
| 454 | Blockcerts | Blockcerts | https://github.com/w3c-ccg/vc-status-rl-2020 | Verifiable Credentials Revocation List 2020 JavaScript implementation | @digitalbazaar/vc-revocation-list | https://github.com/blockchain-certificates/vc-revocation-list | Code | Development; Verifiable Credentials | 2023-01-09 | |||||||||||||||||||||||||||||||
| 455 | Blockcerts | Blockcerts | A scaffholding to plug cert-issuer to vc-test-suite | https://github.com/blockchain-certificates/cert-issuer-node-wrapper | Code | Development; Verifiable Credentials | 2023-05-24 | |||||||||||||||||||||||||||||||||
| 456 | Blockcerts | Blockcerts | Verifiable Credentials WG Test Suite | This repository contains the W3C Verifiable Credentials Working Group test suite. Any conforming implementation MUST pass all tests in the test suite. | https://github.com/blockchain-certificates/vc-test-suite | Code | Development; Verifiable Credentials | 2021-10-31 | ||||||||||||||||||||||||||||||||
| 457 | Blockcerts | Learning Machine | The fastest JSON-Schema Validator. Supports draft-06 | The fastest JSON Schema validator for node.js and browser with draft 6 support | https://github.com/learningmachine/ajv | Code | Development; Validation | 2017-05-09 | ||||||||||||||||||||||||||||||||
| 458 | Blockcerts | Blockcerts | Open Badges | Open Badges validation in python | Open Badges Validator Core is a python package designed to verify the validity of Open Badges based on a variety of input sources and present a useful interface for accessing their properties and validation information. HTTP, Python and command line APIs are provided. | https://github.com/blockchain-certificates/openbadges-validator-core | Code | Development; Validation | 2017-10-06 | |||||||||||||||||||||||||||||||
| 459 | Blockcerts | Blockcerts | A Blockcerts verifier and viewer. | A standalone universal viewer & verifier for blockcerts credentials | https://github.com/blockchain-certificates/blockcerts-verifier | Code | Development; Verification | 2023-05-06 | ||||||||||||||||||||||||||||||||
| 460 | Blockcerts | Blockcerts | Python library for verifying Blockcerts. | Library for verifying blockchain certificates. | https://github.com/blockchain-certificates/cert-verifier | Code | Development; Verification | 2020-06-06 | ||||||||||||||||||||||||||||||||
| 461 | Blockcerts | Blockcerts | Javascript library for verifying Blockcerts Certificates | IMPORTANT NOTE: as of version 5 of this library, v1 blockcerts are not supported anymore. Use https://www.npmjs.com/package/@blockcerts/cert-verifier-js-v1-legacy if needed. | https://github.com/blockchain-certificates/cert-verifier-js | Code | Development; Verification | 2023-05-05 | ||||||||||||||||||||||||||||||||
| 462 | Blockcerts | Blockcerts | A web app for viewing and validating Blockchain Certificates | The cert-viewer project is a Flask webapp to display and verify blockchain certificates after they have been issued and to allow learners to request a certificate and generate their own Bitcoin identity needed for the certificate creation process. | https://github.com/blockchain-certificates/cert-viewer | Code | Development; Apps | 2018-05-10 | ||||||||||||||||||||||||||||||||
| 463 | Blockcerts | Blockcerts | An Android app for Blockcerts. | Blockcerts Android application by Learning Machine | https://github.com/blockchain-certificates/wallet-android | Code | Development; Apps | 2023-02-24 | ||||||||||||||||||||||||||||||||
| 464 | Blockcerts | Blockcerts | An iOS wallet for viewing, validating, and sharing certs | This repository contains the core modules used to implement Blockcerts functionality in iOS. | https://github.com/blockchain-certificates/BlockcertsFramework-iOS | Code | Development; Apps | 2022-09-19 | ||||||||||||||||||||||||||||||||
| 465 | Blockcerts | Blockcerts | An iOS wallet for Blockcerts. | Blockcerts mobile app for iOS to receive and share certificates that are verifiable via the blockchain | https://github.com/blockchain-certificates/wallet-iOS | Code | Development; Apps | 2022-02-17 | ||||||||||||||||||||||||||||||||
| 466 | Linked Data | TwoBitHistory | Whatever Happened to the Semantic Web? | In 2001, Tim Berners-Lee, inventor of the World Wide Web, published an article in Scientific American. Berners-Lee, along with two other researchers, Ora Lassila and James Hendler, wanted to give the world a preview of the revolutionary new changes they saw coming to the web. Since its introduction only a decade before, the web had fast become the world’s best means for sharing documents with other people. Now, the authors promised, the web would evolve to encompass not just documents but every kind of data one could imagine | https://twobithistory.org/2018/05/27/semantic-web.html | Post | Getting Started | 2018-05-27 | ||||||||||||||||||||||||||||||||
| 467 | Linked Data | W3C | LinkedData - W3C Wiki | The idea behind these principles is on the one hand side, to use standards for the representation and the access to data on the Web. On the other hand, the principles propagate to set hyperlinks between data from different sources. These hyperlinks connect all Linked Data into a single global data graph, similar as the hyperlinks on the classic Web connect all HTML documents into a single global information space. Thus, LinkedData is to spreadsheets and databases what the Web of hypertext documents is to word processor files. The Linked Open Data cloud diagramms give an overview of the linked data sets that are available on the Web. | https://www.w3.org/wiki/LinkedData | entry | Getting Started | 2016-08-01 | ||||||||||||||||||||||||||||||||
| 468 | Linked Data | W3C | Tim Berners Lee | Linked Data - Design Issues | The Semantic Web isn't just about putting data on the web. It is about making links, so that a person or machine can explore the web of data. With linked data, when you have some of it, you can find other, related, data.<br>Like the web of hypertext, the web of data is constructed with documents on the web. However, unlike the web of hypertext, where links are relationships anchors in hypertext documents written in HTML, for data they links between arbitrary things described by RDF,. The URIs identify any kind of object or concept. But for HTML or RDF, the same expectations apply to make the web grow:<br>- Use URIs as names for things<br>- Use HTTP URIs so that people can look up those names.<br>- When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)<br>- Include links to other URIs. so that they can discover more things. | https://www.w3.org/DesignIssues/LinkedData | https://www.w3.org/DesignIssues/diagrams/lod/597992118v2_350x350_Back.jpg | page | Getting Started | 2006-07-27 | ||||||||||||||||||||||||||||||
| 469 | Linked Data | Semantalytics | Awesome Semantic Web | A curated list of various semantic web and linked data resources. | https://github.com/semantalytics/awesome-semantic-web | list | Getting Started | 2023-04-26 | ||||||||||||||||||||||||||||||||
| 470 | Linked Data | Nandana Mihindukulasooriya | Awesome Linked Data | A list of tools for publishing and consuming Linked Data. | https://github.com/nandana/awesome-linkeddata | list | Getting Started | 2017-03-07 | ||||||||||||||||||||||||||||||||
| 471 | Linked Data | Datahub | An overview of the Linked Open Data datasets. | A group for Linked Open Data datasets. The initial import of data for this group was done in October 2009 from the list of RDF datasets dumps provided by the W3C Linked Open Data Interest Group. | https://datahub.io/collections/linked-open-data | https://datahub.io/static/img/opendata/product.png | list | Getting Started | 2018-05-10 | |||||||||||||||||||||||||||||||
| 472 | Linked Data | W3C | Publishing and consuming Linked Data embedded in HTML | This document provides guidelines for how to create and consume Linked Data embedded in HTML. It extends and updates [HOWTO-LODP] and the [COOL-SWURIS] Note. The examples in this document use RDFa 1.1 and microdata with a special focus on Schema.org vocabulary terms. | https://www.w3.org/2001/sw/interest/ldh/ | https://www.w3.org/2001/sw/interest/ldh/img/acme-tabview.png | page | Getting Started | 2011-06-26 | |||||||||||||||||||||||||||||||
| 473 | Linked Data | Personal | Kerstin Forsberg | Linked Data for Enterprises | Keeping myself up to date on the practical use of Linked Data in Enterprises and related topics | https://kerfors.blogspot.com/ | https://1.bp.blogspot.com/-2T6XUMBB3WU/Vz4Yu-c9wdI/AAAAAAAAE3o/IBYw9dTSb_0JikoLeZ0N9s33OniI0BKMQCKgB/s400/Linked%2BData%2BURIs.png | page | Getting Started | 2016-12-15 | ||||||||||||||||||||||||||||||
| 474 | Linked Data | Read-Write Linked Data | Examples in the Wild << Pretty Awesome List | dokieli is a decentralised article authoring, annotation, and social notification tool which works from Web browsers. It is built with the following principles in mind: freedom of expression, decentralisation, interoperability, and accessibility. | https://github.com/linkeddata/dokieli/wiki | wiki | Getting Started | 2019-07-03 | ||||||||||||||||||||||||||||||||
| 475 | Linked Data | Solid | Understanding Linked Data slide deck (in Remark.js format) | A slide deck introduction to Linked Data aimed at developers. | https://github.com/solid/understanding-linked-data | Presentation | Getting Started | 2019-10-03 | ||||||||||||||||||||||||||||||||
| 476 | Linked Data | LinkedDataTools | Introducing Linked Data And The Semantic Web | What is Linked Data and the Semantic Web and what is all the hype about? Principally, the Semantic Web is a Web 3.0 web technology - a way of linking data between systems or entities that allows for rich, self-describing interrelations of data available across the globe on the web. | http://www.linkeddatatools.com/semantic-web-basics | https://2mye7d.n3cdn1.secureserver.net/wp-content/uploads/2023/02/semantic-web-learning-curve.png | page | Getting Started | 2011-06-12 | |||||||||||||||||||||||||||||||
| 477 | Linked Data | Personal | Ruben Verborgh | Designing a Linked Data developer experience | Making decentralized Web app development fun<br>While the Semantic Web community was fighting its own internal battles, we failed to gain traction with the people who build apps that are actually used: front-end developers. Ironically, Semantic Web enthusiasts have failed to... | https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/ | Post | Main | 2018-12-28 | |||||||||||||||||||||||||||||||
| 478 | Linked Data | WebofTrustInfo | Christopher Lemmer Webber, Mark S. Miller | rwot05-boston | Linked Data Capabilities | Linked Data Signatures enable a method of asserting the integrity of linked data documents that are passed throughout the web. The object capability model is a powerful system for ensuring the security of computing systems. In this paper, we explore layering an object capability model on top of Linked Data Signatures via chains of signed proclamations. fn:1 We call this system "Linked Data Capabilities", or "ld-ocap" for short. | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/lds-ocap.md | Paper | Main | 2022-12-28 | ||||||||||||||||||||||||||||||
| 479 | Linked Data | WebofTrustInfo | rwot3-sf | Identity as Linked Data on Immutable Ledgers | Content creators on the Web are getting a raw deal. They get a fraction of a cent for an ad played on YouTube, and nothing on Facebook, for filling these sites with traffic-driving content. It’s hard to make a living when you’re a creative. Licensing is hard; the user experience is bad, so lawyers and middlemen extract the most value. In the music industry, more money flows into the pockets of distributors than creatives. Consumers are often happy to pay for their content. Instead, they're forced to sit through ads. | https://github.com/WebOfTrustInfo/rwot3-sf/blob/master/topics-and-advance-readings/identity-as-linked-data-on-immutable-ledgers.md | Paper | Main | 2016-10-17 | |||||||||||||||||||||||||||||||
| 480 | Linked Data | WebofTrustInfo | Manu Sporny, Harlan Wood, Noah Thorp, Wayne Vaughn, Christopher Allen, Jason Bukowski, and Dave Longley | rwot3-sf | Blockchain Extensions for Linked Data Signatures | The term Linked Data is used to describe a recommended best practice for exposing, sharing, and connecting information on the Web using standards, such as URLs, to identify things and their properties. When information is presented as Linked Data, other related information can be easily discovered and new information can be easily linked to it. Linked Data is extensible in a decentralized way, greatly reducing barriers to large scale integration.<br>With the increase in usage of Linked Data for a variety of applications, there is a need to be able to verify the authenticity and integrity of Linked Data documents. The Linked Data Signatures specification added authentication and integrity protection to linked data documents through the use of public/private key cryptography without sacrificing Linked Data features such as extensibility and composability. | https://github.com/WebOfTrustInfo/rwot3-sf/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md | Paper | Main | 2016-10-30 | ||||||||||||||||||||||||||||||
| 481 | 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 | ||||||||||||||||||||||||||||||
| 482 | 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 | |||||||||||||||||||||||||||||||
| 483 | 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 | |||||||||||||||||||||||||||||||
| 484 | 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 | Credentials Community Group | 2023-01-22 | https://github.com/w3c-ccg/zcap-spec | ||||||||||||||||||||||||||||||
| 485 | 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 | ||||||||||||||||||||||||||||||||
| 486 | 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 | |||||||||||||||||||||||||||||||
| 487 | 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 | ||||||||||||||||||||||||||||||||
| 488 | 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 | |||||||||||||||||||||||||||||||
| 489 | Linked Data | W3C | Comparison of RDFJS libraries | This is a comparison of JavaScript libraries for working with RDF. | https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries | entry | RDF | 2019-01-18 | ||||||||||||||||||||||||||||||||
| 490 | Linked Data | W3C | RDF.js: The new RDF and Linked Data JavaScript library | A diverse web requires decentralized data storage and maintenance. According to MIT’s Tim Berners-Lee, “it is about making links, so that a person or machine can explore the web of data. With Linked Data, when you have some of it, you can find other, related, data”.<br><br>Zazuko’s CTO Thomas Bergwinkl adds that “Linked Data is built on top of the web stack and the programming language of the web is JavaScript. It is crucial for Web Developers to have access to well-designed JavaScript libraries to work with RDF and Linked Data”.<br><br>The RDFJS W3C Community Group did a tremendous job in defining a standard to represent Linked Data in JavaScript. Several individuals and groups started to implement the RDFJS specification. | https://www.w3.org/community/rdfjs/2018/04/23/rdf-js-the-new-rdf-and-linked-data-javascript-library/ | Post | RDF | 2018-04-23 | ||||||||||||||||||||||||||||||||
| 491 | Linked Data | RCH Working Group | RDF Dataset Canonicalization | RDF [RDF-CONCEPTS] describes a graph-based data model for making claims about the world and provides the foundation for reasoning upon that graph of information. At times, it becomes necessary to compare the differences between sets of graphs, digitally sign them, or generate short identifiers for graphs via hashing algorithms. This document outlines an algorithm for normalizing RDF datasets such that these operations can be performed. | https://w3c.github.io/rdf-canon/spec/ | Report | RDF | 2023-05-24 | https://github.com/w3c/rdf-canon/ | |||||||||||||||||||||||||||||||
| 492 | GS1 | GS1 | GS1 - How we got here | Since 1973, we have opened offices in over 110 countries and amassed more than 2 million members using supply chain standards that make business easier. Learn about key dates in our history.<br>- 1973: The barcode standard is agreed<br>- 1974: The first barcode is scanned<br>- 1977: The GS1 system is launched<br>- 1983: Barcodes are used on wholesale multi-packs<br>- 1989: GS1 moves beyond barcodes<br> - With wide area networks making an impact on supply chains, we create our first international standard for electronic data interchange.<br>- 1990: Responsibilities grow<br> - The US and international arms of GS1 come together formally, creating a single organisation with a presence in 45 countries.<br>- 1995: First healthcare standards created<br>- 1999: The GS1 DataBar arrives<br>- 2000: 90th local office opens<br> - In just ten years, we double the number of countries in which we have a local presence.<br>- 2002: Global standards forum launched<br> - Our Global Standards Management Process is launched. This global forum gives GS1 members one place to discuss standards.<br>- 2004: The first standard for RFID is created<br>- 2007: GS1 enters the business-to-consumer world<br> - As ecommerce grows, we begin to create open standards that give consumers direct access to key product information.<br>- 2013: A 40-year celebration<br> - With a presence in over 100 countries and more than a million members, we celebrate 40 years of the global language of business. | https://www.gs1.org/about/how-we-got-here | page | Main | 2023-04-25 | ||||||||||||||||||||||||||||||||
| 493 | GS1 | GS1 | Standards development | A neutral participant, GS1 facilitates dialogue and the development of standards-based solutions among business and technical people from nearly sixty countries. Industries represented include retail and consumer goods, fresh foods, healthcare, transport and logistics, governments and many more.<br><br>The GSMP (Global Standards Management Process) is a community-based forum for businesses facing similar problems to work together and develop standards-based solutions. Standards created by industry, for industry. | The GSMP (Global Standards Management Process) is a community-based forum for businesses facing similar problems to work together and develop standards-based solutions. Standards created by industry, for industry. | https://www.gs1.org/standards/development | page | Main | 2023-04-25 | |||||||||||||||||||||||||||||||
| 494 | GS1 | GS1 | How we develop standards | Our standards development team guide the regular upgrading of our standards through a document development life cycle whose rules everyone agrees to. The Global Standards Management Process (GSMP) enables us to reach consensus around the creation and adoption of new standards smoothly and rapidly! | We develop our global supply chain standards in partnership with the industry experts and business teams who actually use them. Find out how we do it. | https://www.gs1.org/how-we-develop-standards | page | Main | 2023-04-27 | |||||||||||||||||||||||||||||||
| 495 | GS1 | IDCommons | IIW30 | GS1's decentralized approach to resolving identifiers over HTTPS | Slides are at http://docs.google.com/presentation/d/1fLDETcghxxRfac7mDCTGpqktaVnn9bjl/edit# General principles paper is at http://gs1.github.io/DigitalLinkDocs/principles/<br><br>GS1 DIgital Link standard makes the standard product Identifier - the “UPC” code web resolvable. Making it do more than go beep at the check out.<br><br>SSI / DIDs “not central point of issuance, no single point of failure”...but we can meet those requirements with persistent identifiers with centralized federation… centralized + delegation can work. | https://iiw.idcommons.net/GS1%27s_decentralized_approach_to_resolving_identifiers_over_HTTPS | Session Notes | Main | 2009-06-18 | |||||||||||||||||||||||||||||||
| 496 | GS1 | IDCommons | https://gs1.github.io/DigitalLinkDocs/principles/ | Phil Archer, Mark Harrison, Henri Barthel | IIW30 | Decentralized resolution of identifiers with HTTPS | 11 Transferable Principles from GS1 Digital Link | https://docs.google.com/presentation/d/1fLDETcghxxRfac7mDCTGpqktaVnn9bjl/edit#slide=id.p1 | Presentation | Main | 2020-04 | |||||||||||||||||||||||||||||
| 497 | GS1 | GS1 | GSMP Manual | The GSMP 4-Step Process is designed to ensure that business needs and requirements are understood before standards and guidelines are developed, and that supporting materials are created afterward. Each step culminates in the completion of one or more outputs, created through a consensus-based process within a working group and with larger consensus confirmed through community review and eBallot. | https://www.gs1.org/docs/gsmp/GSMP_Manual.pdf | docs | Global Standards Mapping Process | 2022-07 | ||||||||||||||||||||||||||||||||
| 498 | GS1 | GS1 | Global Data Model (GDM) Governance Manual | The retail landscape is changing at an unprecedented rate. In this connected world, consumers increasingly rely on product information for purchasing decisions. The purpose of the Global Data Model (GDM) is to simplify and harmonise the exchange of master data. The GDM will identify and define—in a globally consistent way—the set of foundational attributes needed to list/order, move, store and sell a product, both digitally and physically. By harmonising foundational data across the industry around the globe, it will enable an improved consumer experience and reduce complexity by delivering more reliable and complete product information to consumers. | https://www.gs1.org/sites/default/files/docs/gsmp/gdm_manual_i1_a_2020-03-19.pdf | docs | Global Standards Mapping Process | 2020-03-19 | ||||||||||||||||||||||||||||||||
| 499 | GS1 | GS1 | GSMP Value Statement | Are business challenges holding back your company’s full potential and growth? You are not alone. Business is easier when you speak the same language as your customers, suppliers and partners. Though we all work in our own way, problems and differences become solutions when we all work together. That’s where GS1 can help.<br><br>The GSMP is a community-based forum for businesses facing similar problems to work together and develop standards-based solutions to address them. Standards created by industry, for industry. | https://www.gs1.org/sites/default/files/docs/gsmp/gsmp_execsummary.pdf | docs | Global Standards Mapping Process | 2015-10-02 | ||||||||||||||||||||||||||||||||
| 500 | GS1 | GS1 | https://www.gs1.org/standards/development-work-groups | GSMP Data Accuracy SMG | This processes all maintenance Work Requests for the **[GS1 Package Measurement Rules Standard](https://www.gs1.org/docs/gdsn/3.1/GS1_Package_Measurement_Rules.pdf)** and the **[Package Measurement Rules Implementation Guideline](https://www.gs1.org/sites/default/files/docs/gdsn/GDSN_Pack_Measure_Rules_Implementation_Guide.pdf)**. This group acts as a pool of experts for all Data Accuracy SMG work requests and coordinate with associated Mission Specific groups as defined in the GSMP Manual. The work the Data Accuracy SMG allows our community to increase savings throughout the supply chain by synchronising accurate dimensions and weight data which enables better transportation, logistics and retail shelf planning. | https://www.gs1.org/standards/development-work-groups#DA | Working Group | Working Groups | 2010-04-15 | |||||||||||||||||||||||||||||||
| 501 | GS1 | GS1 | https://www.gs1.org/standards/development-work-groups | GSMP Electronic Data Interchange (EDI) SMG | This group maintains and improves [GS1 EDI (Electronic Data Interchange) standards](https://www.gs1.org/standards/edi). Examples of standards maintained in this group (but not limited to) are:<br>- EANCOM®<br>- GS1 XML<br>- GS1 UN/CEFACT XML | https://www.gs1.org/standards/development-work-groups#EDI | Working Group | Working Groups | 2010-04-15 | |||||||||||||||||||||||||||||||
| 502 | GS1 | GS1 | https://www.gs1.org/standards/development-work-groups | GSMP Global Master Data (GMD) SMG | The group maintains and improves the GS1 Master Data standards. Examples of standards maintained in this group (but not limited to) are:<br>- [Master Data Standards](https://www.gs1.org/standards/gs1-global-data-model)<br>- GS1 Attributes, definitions, code lists, and guidance definitions<br>- [GDSN solutions and GDSN Validation Rules](https://www.gs1.org/standards/gdsn)<br>- GS1 Web Vocabulary<br>- Global Data Model Standards and Attribute Definitions for Business | https://www.gs1.org/standards/development-work-groups#GMD | Working Group | Working Groups | 2013-12-14 | |||||||||||||||||||||||||||||||
| 503 | GS1 | GS1 | https://www.gs1.org/standards/development-work-groups | GSMP Global Product Classification (GPC) SMG | The GPC Standards Maintenance Group maintains and improves the GS1 Global Product Classification (GPC) standard.<br><br>The [GS1 Global Product Classification (GPC) standard](https://www.gs1.org/standards/gpc) helps global trading partners to group products in the same way, everywhere in the world. The resulting common business language is clear and instantly understandable. | https://www.gs1.org/standards/development-work-groups#GPC | Working Group | Working Groups | 2010-04-15 | |||||||||||||||||||||||||||||||
| 504 | GS1 | GS1 | https://www.gs1.org/standards/development-work-groups | GSMP Identification SMG | The ID Standards Maintenance Group maintains and improves the GS1 Automatic Identification and Data Capture (AIDC) standards including Identification Keys, Barcodes, Electronic Product Code, and Radio-Frequency Identification (RFID) standards.<br><br>- The GS1 General Specification is the core foundational GS1 standard that defines how identification keys, data attributes and barcodes must be used in business applications<br>- GS1 Identification Keys provides companies efficient ways to access and share information about items in their supply chains.<br>- Barcodes are symbols that can be scanned electronically using laser or camera-based systems.<br>- The Electronic Product Code™ (EPC) is syntax for unique identifiers assigned to physical objects, unit loads, locations, or other identifiable entity playing a role in business operations.<br>- GS1's EPC Tag Data Standard (TDS) defines the Electronic Product Code (EPC), including its correspondence to GS1 keys and other existing codes. TDS also specifies data that is carried on Gen 2 RFID tags, including the EPC, User Memory data, control information, and tag manufacture information. | https://www.gs1.org/standards/development-work-groups#ID | Working Group | Working Groups | 2010-04-15 | |||||||||||||||||||||||||||||||
| 505 | GS1 | GS1 | GSMP Traceability and Event Sharing Standards Maintenance Group SMG | The SMG maintains updates to the GS1 EPCglobal standards that support physical event capture and sharing and the [Global Traceability Standard that supports tracking and tracing of goods](https://www.gs1.org/sites/default/files/docs/gsmp/call_to_action_gtc_h.pdf) and information about the goods. This includes all simple work requests indicated as impacting the event data sharing and traceability standards.<br><br>In addition, the group acts as a pool of experts for all Mission Specific Work Groups that are related to the SMG, as defined in the GSMP Manual in section 3.4. Work Groups. | https://www.gs1.org/standards/development-work-groups#TRACE_EVENT | Working Group | Working Groups | 2011-05-26 | ||||||||||||||||||||||||||||||||
| 506 | GS1 | GS1 | GSMP Digital Signature MSWG | Provide a GS1 standard solution approach to digital signatures. Otherwise, there will be no open, brand owner determined digital signatures to set as an alternative to proprietary digital signature use in barcodes with GS1 standards. | Mission-specific Working Groups (MSWGs) develop new standards | https://www.gs1.org/standards/development-work-groups#DigitalSignature | Working Group | Working Groups | 2020-03-26 | |||||||||||||||||||||||||||||||
| 507 | GS1 | GS1 | GSMP EPCIS & CBV 2.0 MSWG | Since its initial ratification as an EPCglobal standard in 2007 and its subsequent integration into the GS1 “Share” portfolio, EPCIS and its companion standard the Core Business Vocabulary (CBV) have been updated twice (2014 and 2016) and published by ISO (as ISO/IEC 19987 and 19988, respectively). In the meantime, EPCIS and the CBV have gained importance as visibility enablers in various industries. Updates are needed to ensure the relevance of these standards into the coming decades. | Mission-specific Working Groups (MSWGs) develop new standards | https://www.gs1.org/standards/development-work-groups#EPCISCBV | Working Group | Working Groups | 2018-02-19 | |||||||||||||||||||||||||||||||
| 508 | GS1 | GS1 | GSMP GLN Modernisation MSWG | This work group will update the GLN Standards to be more clear and concise and provide guidance to enable industry partners to create, manage, share, and use the GLN to meet their party and location use cases needs in a scalable, standardised manner. | Mission-specific Working Groups (MSWGs) develop new standards | https://www.gs1.org/standards/development-work-groups#GLNM | Working Group | Working Groups | 2022-08-16 | |||||||||||||||||||||||||||||||
| 509 | Object Capabilities | Personal | Dan Connolly | Awesome Object Capabilities and Capability-based Security | Capability-based security enables the concise composition of powerful [patterns](https://github.com/dckc/awesome-ocap/wiki) of cooperation without vulnerability. [What Are Capabilities?](http://habitatchronicles.com/2017/05/what-are-capabilities/) explains in detail. | https://github.com/dckc/awesome-ocap | list | Main | 2023-03-03 | |||||||||||||||||||||||||||||||
| 510 | Object Capabilities | Wikipedia | Object Capability Model | Computer scientist E. Dean Tribble stated that in smart contracts, identity-based access control did not support well dynamically changing permissions, compared to the object-capability model. He analogized the ocap model with giving a valet the key to one's car, without handing over the right to car ownership.<br><br>The structural properties of object capability systems favor modularity in code design and ensure reliable encapsulation in code implementation.<br><br>These structural properties facilitate the analysis of some security properties of an object-capability program or operating system. Some of these – in particular, information flow properties – can be analyzed at the level of object references and connectivity, independent of any knowledge or analysis of the code that determines the behavior of the objects. As a consequence, these security properties can be established and maintained in the presence of new objects that contain unknown and possibly malicious code. | https://en.wikipedia.org/wiki/Object-capability_model | entry | Main | 2023-04-12 | ||||||||||||||||||||||||||||||||
| 511 | Object Capabilities | eRights | Mark S. Miller | Object Capabilities | The capability model is, in a sense, the object model taken to its logical extreme. Where object programmers seek modularity -- a decrease in the dependencies between separately thought-out units -- capability programmers seek security, recognizing that required trust is a form of dependency. Object programmers wish to guard against bugs: a bug in module A should not propagate to module B. Capability programmers wish to guard against malice. However, if B is designed to be invulnerable to A's malice, it is likely also invulnerable to A's bugs. | E: Cryptographic Capabilities for Distributed Smart Contracting | http://erights.org/elib/capability/ode/ode-capabilities.html | http://erights.org/elib/capability/ode/images/money.png | page | Main | 1998-10-03 | |||||||||||||||||||||||||||||
| 512 | Object Capabilities | IDCommons | IIW | DIDAuth + Obj. Cap. - IIW | What is DIDAuth and how is it compatible with Object Capabilities?<br>We started by defining and describing object capabilities:<br>- A Capability is a Transferable Unforgeable Permission. It can be implemented with unguessable URLS or signed objects.<br>- A Java Program object reference is a capability, it allows for actions on the subject (the object instance).<br>- A stronger implementation of object capabilities involves a digital certificate issued by a public key, for a resource with a set of supported methods:<br>`Issuer: AlicePubKey`<br>`Resource: did:dad:0x123`<br>`Actions: Read,Write`<br>`Signature: 0x456` | https://iiw.idcommons.net/DIDAuth_%2B_Obj._Cap. | https://iiw.idcommons.net/images/c/cb/TH1G.jpg | Session Notes | Literature | 2018-10-31 | ||||||||||||||||||||||||||||||
| 513 | Object Capabilities | WebofTrustInfo | Bill Tulloh | rwot8-barcelona | Applying the Principle of Least Authority to User Interaction | Object capabilities (ocaps) are increasingly recognized as an important tool for achieving the goals of self-sovereign identity. Many of the principles of self-sovereign identity, such as minimization and protection, can best be achieved through the disciplined pursuit of the principle of least authority that ocaps enable. This paper examines how POLA can be extended to better protect users when exercising their self-sovereign identity. | https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/Applying_POLA_to_User_Interaction.md | Paper | Literature | 2019-02-25 | ||||||||||||||||||||||||||||||
| 514 | Object Capabilities | WebofTrustInfo | James Foley | rwot7-toronto | Introductory Capability DHT | The Object Capability software design paradigm is a powerful philosophy for the programming of decentralized applications particularly in the realms of security and rights management. | https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/introductory-capability-dht-concept.md | Paper | Literature | 2019-02-08 | ||||||||||||||||||||||||||||||
| 515 | Object Capabilities | WebofTrustInfo | Joe Andrieu, Nathan George, Christophe Macintosh, Ouri Poupko, Antoine Rondelet, Andrew Hughes | rwot7-toronto | Models of Identity | **Security** • **Liberty** • **Data** • **Relationship** • **Capability** <br><br>Considering different models for handling identity information allows reconciliation, and creates opportunities to address primary use cases across paradigms, increasing overall strength and security of a solution.<br>[...]<br>In the Object Capabilities model, authorization is managed by creating, sharing, attenuating, and using “capabilities” instead of, for example, access control lists. If you have a valid “capability”, you have the authorization. Like a car key, Object Capabilities may be used no matter who you are. This model shifts the burden of identification from error-prone correlations to directly work with individuals’ actual capabilities. | https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/mental-models.md | Paper | Literature | 2020-05-17 | ||||||||||||||||||||||||||||||
| 516 | Object Capabilities | WebofTrustInfo | Manu Sporny, Dave Longley, Christopher Lemmer Webber | rwot7-toronto | Cryptographic and Data Modeling Requirements from RWoT | This paper introduces the uninitiated to the requirements that have been identified over the years that are driving the community toward certain technological solutions.<br><br>Rebooting the Web of Trust is a community that is attempting to create a decentralized ecosystem that enables people to be in control of various aspects of their data and identity information. The group often talks about Decentralized Identifiers, Verifiable Credentials, Object Capabilities, ed25519 keys, cryptographic identifiers, and other technologies but rarely spends time documenting how we got here. | https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/topics-and-advance-readings/crypto-data-model-requirements.md | Paper | Literature | 2018-08-23 | ||||||||||||||||||||||||||||||
| 517 | Object Capabilities | WebofTrustInfo | Christopher Lemmer Webber | rwot6-santabarbera | Recent happenings with Linked Data Capabilities | One of the outputs from Rebooting Web of Trust Fall 2017 was a writeup on Linked Data Capabilities based on discussions from the workshop (and particularly thanks to the guide of Mark S. Miller's longstanding work on object capabilities). While the writeup speaks for itself, in short Linked Data Capabilities provide a way to encode object capability security to linked data systems. Much has happened since then.<br><br>After the workshop ideas from the paper were reified into specification form and the W3C Credentials Community Group has taken on the specification as an official work item of the group. Some changes have happened in the design of Linked Data Capabilities from the initial Rebooting Web of Trust paper | https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/ld-ocap-recent-happenings.md | Paper | Literature | 2018-03-02 | ||||||||||||||||||||||||||||||
| 518 | Object Capabilities | WebofTrustInfo | Christopher Lemmer Webber and Christopher Allen | rwot5-boston | Smarm: Requirements for a smart-signatures Scheme | [Smart signatures](https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/smarm.md) are desirable, but how to implement them? We need a language that is powerful and flexible enough to meet our needs while safe and bounded to run while remaining simple enough to feasibly implement.<br><br>[Scheme](https://en.wikipedia.org/wiki/Scheme_programming_language) is a turing-complete language with a (at least stated) fondness for minimalism. Unfortunately Scheme on its own is neither "safe" nor (necessarily) deterministic. Thankfully we can get the properties we want through:<br><br>- Making object capabilities a core part of the language. Specifically, [Jonathan Rees' "W7 security kernel"](http://mumble.net/~jar/pubs/secureos/secureos.html) demonstrates that a pure lexically scoped environment is itself an appropritate substrate for object capabilities.<br>- Restricting space and time precisely in a way that is deterministic and reproducible.<br>- Removing sources of external side effects. | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/smarm.md | Paper | Literature | 2017-10-05 | ||||||||||||||||||||||||||||||
| 519 | Object Capabilities | WebofTrustInfo | Adrian Gropper, Drummond Reed, Mark S. Miller | rwot5-boston | Identity Hubs Capabilities Perspective | Identity Hubs as currently proposed in the Decentralized Identity Foundation (DIF) are a subset of a general Decentralized Identifier (DID) based user-controlled agent, based on ACLs rather than an object-capabilities (ocap) architecture. The current approach has both security and scalability issues. Transitioning the Hubs design to an ocap model can be achieved by introducing an UMA authorization server as the control endpoint. This avoids creating confused-deputy security issues and expands scale by enabling the hub to delegate access to resources not stored in the hub itself. | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/identity-hubs-capabilities-perspective.md | Paper | Literature | 2017-10-14 | ||||||||||||||||||||||||||||||
| 520 | Object Capabilities | WebofTrustInfo | Christopher Lemmer Webber, Mark S. Miller | rwot5-boston | Linked Data Capabilities | Linked Data Signatures enable a method of asserting the integrity of linked data documents that are passed throughout the web. The object capability model is a powerful system for ensuring the security of computing systems. In this paper, we explore layering an object capability model on top of Linked Data Signatures via chains of signed proclamations. fn:1 We call this system "Linked Data Capabilities", or "ld-ocap" for short. | https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/lds-ocap.md | Paper | Literature | 2022-11-28 | ||||||||||||||||||||||||||||||
| 521 | DIDComm | CCG Mailing List | Daniel Hardman | announcement: DIDComm user group | Now that the [DIDComm v2 spec](https://identity.foundation/didcomm-messaging/spec/) is nearing completion, and there are [robust libraries in multiple programming languages](https://github.com/decentralized-identity/didcomm-messaging#implementations), we are starting a user group to share learnings as we put DIDComm into production. We will organize community resources, produce a handbook, foster application-level protocol creation, maintain the [didcomm.org website](https://didcomm.org) and [repo](https://github.com/decentralized-identity/didcomm.org), and recommend best practices. | https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0168.html | Discussion | main | 2022-01-20 | |||||||||||||||||||||||||||||||
| 522 | DIDComm | CCG Mailing List | https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0032.html | DIDComm V2 Primer | 1. What it is<br>2. What it does and doesn't do<br>3. Relationship to WACI-DIDComm, CHAPI, OIDC-SIOP<br>4. Versions<br>5. Implementations | https://lists.w3.org/Archives/Public/public-credentials/2022Apr/att-0032/DIDComm_v2_Primer.pdf | Discussion | main | 2022-04 | |||||||||||||||||||||||||||||||
| 523 | DIDComm | didcomm.org | didcomm.org | DIDComm lets people and software use [DIDs](https://www.w3.org/TR/did-core/) to communicate securely and privately over many channels: the web, email, mobile push notifications, QR codes, Bluetooth, message queues, sneakernet, and more. | https://didcomm.org/ | site | main | |||||||||||||||||||||||||||||||||
| 524 | DIDComm | DIF | DIDComm WG | https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_DIDcomm_WG_Charter_v1.pdf | DID Communications Working Group | Join this group to contribute to specs that embody a method for secure, private and authenticated message-based communication, where trust is rooted in DIDs and used over a wide variety of transports. | https://identity.foundation/working-groups/did-comm.html | Working Group | Working Group | 2020-09-18 | https://github.com/decentralized-identity/didcomm-messaging/ | https://dif.groups.io/g/didcomm-wg | ||||||||||||||||||||||||||||
| 525 | DIDComm | DIF | DIDComm V2 reaches approved spec status! | Following the approval of the Decentralized Identifiers (DID) Core Spec by the W3C as an official open web standard, the Decentralized Identity Foundation (DIF) announced the approval of the DIDComm v2 specification. Combined, this represents a major step forward in the acceptance of decentralized identity, one that opens the path to widespread adoption and further development especially with regard to the types of peer-to-peer communication now possible.<br><br>DIDComm defines how messages are composed into application-level protocols and workflows. | DIDComm v2 has now reached DIF Approved Status, joining SideTree as a complete and approved open-source specification. | https://blog.identity.foundation/didcomm-v2/ | Post | Working Group | DIDComm WG | 2022-07-26 | ||||||||||||||||||||||||||||||
| 526 | DIDComm | DIDComm WG | Sam Curren, Tobias Looker, Oliver Terbu, Kyle Den Hartog, Baha Shaaban, Drummond Reed, Steve McCown, Troy Ronda, George Aristy, Vyacheslav Gudkov, Alexander Shcherbakov, Alexander Martynov, Daniel Buchner, Devin Fisher, Orie Steele, Brian Richter, Juan Caballero, @liormargalit, Timo Glastra, Andrew Whitehead, Nader Helmy, Markus Sabadello, Patrick McClurg, Stephen Curran, Daniel Hardman, Moe Jangda | Indicio, TBD, SICPA, Danube Tech, MATTR, Animo, Aviary, Transmute, Centre, Microsoft, Evernym, DSR, SecureKey, ConsenSys, BCGov, Anonyome | DIDComm Messaging v2.1 Editor’s Draft | DIDComm enables higher-order protocols that inherit its security, privacy, decentralization, and transport independence. Examples include exchanging verifiable credentials, creating and maintaining relationships, buying and selling, scheduling events, negotiating contracts, voting, presenting tickets for travel, applying to employers or schools or banks, arranging healthcare, and playing games. Like web services atop HTTP, the possibilities are endless; unlike web services atop HTTP, many parties can participate without being clients of a central server, and they can use a mixture of connectivity models and technologies. | https://identity.foundation/didcomm-messaging/spec/ | Specification | Working Group | 2023-04-26 | https://github.com/decentralized-identity/didcomm-messaging | |||||||||||||||||||||||||||||
| 527 | DIDComm | DIDComm WG | DIDcomm WG Operating Addendum | We are designing communications protocols specifically for use with the decentralized identifier specification at W3C (https://www.w3.org/TR/did-core/). The DID Core specification and the surrounding family of DID specifications (e.g https://w3c-ccg.github.io/did-resolution/) represent the format for entity identification in our DIDComm efforts. | https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_DIDcomm_WG_Operating_Addendum_v1.pdf | Page | Working Group | 2020-09-18 | ||||||||||||||||||||||||||||||||
| 528 | DIDComm | DIDComm WG | DIF starts DIDComm Working Group | Over the past few months, the DIF and Hyperledger Aries community have come together and agreed to work on a common work item aimed at developing secure communication based on Decentralized Identifiers (DIDs) — hence the name DIDComm, which is short for DID Communication. Significant prior work in developing a messaging-based communication protocol using DIDs has been incubating in the HyperLedger (HL) Aries community, with the progress of this effort evident in the resulting [Aries RFCs](https://github.com/hyperledger/aries-rfcs). To address the requirements of a broader and more heterogeneous community we selected DIF as the place to pursue the next phase of work associated with this effort. Presenting the progress of DIDcomm to other relevant working groups will drive the interoperability between the various decentralized identity vendors and hence enabling a range of decentralized identity-related use cases. | https://medium.com/decentralized-identity/dif-starts-didcomm-working-group-9c114d9308dc | Post | Working Group | 2020-01-09 | ||||||||||||||||||||||||||||||||
| 529 | DIDComm | DIDComm WG | decentralized-identity/DIDComm-js | DIDComm JS LibA shared effort with the HL Aries project to create a standardized means of authenticated general message passing between DID controllers. More information will be added soon. | https://github.com/decentralized-identity/DIDComm-js | Code | Working Group | 2020-01-09 | ||||||||||||||||||||||||||||||||
| 530 | DIDComm | IDCommons | https://docs.google.com/presentation/d/16HTPyZV_-BtM6EifQpxjivRHKYUeVtOAReUD1eGUA9M/edit?usp=sharing | Sam Curren | IIW | 2D/ Why the Internet Needs DIDComm - IIW | - Enables Verifiable Communication<br> - Intelligence at the edge (like email)<br> - Protocol Based (like email)<br> - Supports HTTP(s) (like APIs) and others as a transport<br> - Bluetooth enables Edge to Edge transport<br> - Mobile / Offline Friendly (like email)<br> - Supports rotating from one DID to another<br> - Security independent of transport<br> - Protocol development becomes easier and more robust (unlike email) | https://iiw.idcommons.net/2D/_Why_the_Internet_Needs_DIDComm | Session Notes | Explainer | 2021-05-06 | |||||||||||||||||||||||||||||
| 531 | DIDComm | IDCommons | Paul Knowles | IIW | 2E/ Decentralized Semantics 101 - IIW | A digital network must contain authenticable data entry and immutable data<br> <br> capture elements in order to maintain balance and integrity.<br> <br> Within the context of a decentralized network, these fundamentals enable a self-regulating system where ...<br> <br> (1) data inputs can be trusted as having come from an assured source under the control of a governing entity; and<br> <br> (2) semantic items ensure that the meaning and use of inputted data remains unaltered for all interacting actors. | https://iiw.idcommons.net/2E/_Decentralized_Semantics_101 | Session Notes | Explainer | 2021-05-06 | ||||||||||||||||||||||||||||||
| 532 | DIDComm | IDCommons | Phil Windley | IIW | 21A/ DIDComm and the Self-Sovereign Internet - IIW | DID-based relationships are the foundation of self-sovereign identity (SSI). The exchange of DIDs to form a connection with another party gives both parties a relationship that is self-certifying and mutually authenticated. Further, the connection forms a secure messaging channel called DID Communication or DIDComm. DIDComm messaging is more important than most understand, providing a secure, interoperable, and flexible general messaging overlay for the entire internet. | https://iiw.idcommons.net/21A/_DIDComm_and_the_Self-Sovereign_Internet | Session Notes | Explainer | 2021-05-06 | ||||||||||||||||||||||||||||||
| 533 | DIDComm | Personal | Phillip J. Windley | DIDComm and the Self-Sovereign Internet | DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification. | https://www.windley.com/archives/2020/11/didcomm_and_the_self-sovereign_internet.shtml | Post | Explainer | 2020-11-11 | |||||||||||||||||||||||||||||||
| 534 | DIDComm | DIF | Kaliya Young | Why we need DIDComm - Identity Woman | This is the text of an email I got today from a company that I had a contract with last year [...] I was reminded quite strongly why we need DIDComm as a protocol to enable the secure transport of all sorts of things not just signed VCs but intermediate uses | https://identitywoman.net/why-we-need-didcomm/ | Post | Explainer | 2022-01-12 | |||||||||||||||||||||||||||||||
| 535 | DIDComm | Personal | Daniel Hardman | DIDComm Mythconceptions | DIDComm is a peer-to-peer communication technology for SSI (self-sovereign identity) with security and privacy properties rooted in DIDs (decentralized identifiers). Its core value proposition is often misunderstood or oversimplified. This webinar provides a proper mental model. | https://www.youtube.com/watch?v=rwvQdRyMeY4 | https://i.ytimg.com/vi/rwvQdRyMeY4/maxresdefault.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGGUgXig_MA8=&rs=AOn4CLCxo_GS9BmeYLTCl5mB-923nmd_Vg | Video | Explainer | 2021-11-10 | ||||||||||||||||||||||||||||||
| 536 | DIDComm | twit.tv | Sam Curren | DIDCOMM - Sam Curren, Importance of DIDs | Sam Curren unpacks for Doc Searls and Dan Lynch why DIDs and DIDcomm are the best approach to identity—and to making people first-class citizens on the Internet. Curren also discusses the origin story of picos and the advantages of nomadic living and hacking. | https://twit.tv/shows/floss-weekly/episodes/685 | episode | Explainer | 2022-06-15 | |||||||||||||||||||||||||||||||
| 537 | DIDComm | Hyperledger | Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats | An optional mechanism for providing credential supplements during issuance. Supplements are also used in credential presentation. | https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2 | rfc | RFCs | Aries RFC | 2021-04-15 | |||||||||||||||||||||||||||||||
| 538 | DIDComm | Hyperledger | Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats | A minor update to add mechanism for a Verifier to request the Prover submit multiple presentations in the "presentation" message(s), each presentation sourced from different credentials that satisfy the presentation request. An example use of this capability is an employer (Verifier) requesting multiple "proof of employment" presentations from a job application (Prover), each satisfying the one presentation request. | https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2 | rfc | RFCs | Aries RFC | 2021-04-15 | |||||||||||||||||||||||||||||||
| 539 | DIDComm | IDCommons | IIW | DIDComm V2: Implementation and integration 'technical' - did:key and did:keri resolvers, seamless and partial integrations | Technical session covering basics of DIDComm v2 Rust implementation (didcomm-rs), including JWM message format overview, JWE/JWM envelopes and key identifiers structures as well as cryptography usage. In addition we’ve discussed how key resolution of public keys happening from `kid` and `skid` envelope header fields using plugable resolvers and private keys resolver using Vault Key provider in form of “Universal wallet” spec implementation [wallet-rs]. | https://iiw.idcommons.net/11D/_DIDComm_V2:_Implementation_and_integration_%27technical%27_-_did:key_and_did:keri_resolvers,_seamless_and_partial_integrations- | Session Notes | Development | 2021-05-07 | |||||||||||||||||||||||||||||||
| 540 | DIDComm | Jolocom | Ivan Temchenko | didcomm-rs implementation | What is this talk about?<br><br>• didcomm-rs implementation<br>• Resolver[s] integration<br>• Application level integration (with wallet-rs)<br>• End-to-end consuming application example demo – simple console chat application based on DIDComm v2 and did:key/did:keri (with resolvers)<br>• Floor open for discussions | https://drive.google.com/file/d/1dn5f2SqnCeQocOy5quJD9gpMPipKRmdC/view?usp=sharing | Presentation | Development | 2021-04-21 | |||||||||||||||||||||||||||||||
| 541 | DIDComm | DIF | Rust implementation of DIDComm v2 | This is a sample implementation of the DIDComm V2 spec. The DIDComm V2 spec is still actively being developed by the DIDComm WG in the DIF and therefore subject to change. | https://github.com/decentralized-identity/didcomm-rs | Code | Development | 2022-10-10 | ||||||||||||||||||||||||||||||||
| 542 | DIDComm | uPort | Oliver Terbu | uPort | Trusted P2P messaging with DIDs DIDComm and VCs | about their path towards trusted P2P messaging and announces the [DIDAgent Framework (DAF)](https://github.com/uport-project/daf)<br>when we speak about a DID, then we need to be more precise and also speak about the particular DID method of that DID which defines the CRUD operations on a target system such as Ethereum. | A Decentralized Identifier (DID) is a stable identifier in form of an URI that introduces a level of indirection for key management and managing other useful information such as service endpoints. It… | https://medium.com/uport/trusted-p2p-messaging-with-dids-didcomm-and-vcs-398f4c3f3cda | Post | Development | 2020-11-12 | |||||||||||||||||||||||||||||
| 543 | DIDComm | uPort | Oliver Terbu | DIDComm Messaging through libp2p | We outlined the next generation decentralized messaging solution built on top of [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/), [DIDs](https://www.w3.org/TR/did-core/) and [VCs](https://www.w3.org/TR/vc-data-model/) and a [libp2p](https://libp2p.io/) overlay network. We presented how Alice and Bob establish a connection, exchange messages and demonstrated what connection types are supported. | With InterPlanetary File System (IPFS) the Web3 community has established a critical piece of infrastructure that is used by the majority of web3 protocols to different degrees. Libp2p is part of the… | https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062 | Post | Development | 2021-11-30 | ||||||||||||||||||||||||||||||
| 544 | DIDComm | WebofTrustInfo | Karim Stekelenburg | Animo Solutions | Advanced DIDComm Messaging | in order for DIDComm to provide a potential replacement for commonly used chat protocols like WhatsApp (Extensible Messaging and Presence Protocol (XMPP)), Telegram (MTProto), or Signal (Signal Protocol), it needs to support modern chat features we use everyday | https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md | Paper | 0.1 | Development | 2022-07-19 | |||||||||||||||||||||||||||||
| 545 | DIDComm | DATEV | Tim Vorgs | DIDComm & DIDComm Messaging | Based on the research project we conducted with SAP, we developed a Proof of Concept (PoC for order-to-cash-business processes. As part of this PoC, we integrated DIDComm based communication to seamlessly transfer data within the boundaries of the process. The overall steps are: | https://medium.com/datev-techblog/didcomm-didcomm-messaging-3e10fbf12bb8 | https://miro.medium.com/v2/resize:fit:1200/1*prcKX5OvEifMsbSiijDj1A.png | Post | Development | 2022-07-18 | ||||||||||||||||||||||||||||||
| 546 | DIDComm | DIF | DIF F2FJan21 - DIDComm Demo Session with Ivan Temchenko, Tobias Looker, and Oliver Terbu | During the live demo he showed the message lifecycle in various setups using the new, [open source didcomm-rs library](http://github.com/jolocom/didcomm-rs) on GitHub | In this informal F2F side-session, Jolocom's Ivan Temchenko gives a detailed tour of their core DIDComm v2 library in Rust, followed by a brief CLI demo from... | https://www.youtube.com/watch?v=SaNvIorKQ9I&feature=youtu.be | Video | Development | 2021-01-26 | |||||||||||||||||||||||||||||||
| 547 | DIDComm | gold and double blue | Siddhi | Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform | Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform<br>- Presented in 7th IEEE International Conference on Smart Computing(IEEE SmartComp 2021) | - Siddhi - Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform- Presented in 7th IEEE International Conference on Smar... | https://www.youtube.com/watch?v=lzS49R52PwA | Video | Implementation | 2021-08-11 | ||||||||||||||||||||||||||||||
| 548 | DIDComm | Personal | https://didcomm.org/shorten-url/1.0/ | Timo Glastra | Just got my first DIDComm protocol published on the https://didcomm.org website. | A protocol to request a shortened URL for a given URL. For example, an agent requesting a shortened out of band invitation url from a mediator. | https://twitter.com/TimoGlastra/status/1572976791136137216 | tweet | Implementation | 2022-08-22 | ||||||||||||||||||||||||||||||
| 549 | DIDComm | DIF | DIDComm: ECDH-1PU Implementation | In short, ECDH-1PU is a key derivation process that allows for sender authenticity and enables a “[Perfect Forward Secrecy](https://www.wired.com/2016/11/what-is-perfect-forward-secrecy/#:~:text=Perfect%20forward%20secrecy%20means%20that,of%20the%20user%27s%20sensitive%20data.)” mechanism, in addition to significant performance gains over JWS message nested in a JWE envelope, as used by existign ECDH-ES aproaches. | ECDH-1PU is a key derivation process that offers sender authenticity, as well as significant performance gains over existing ECDH-ES aproaches. | https://blog.identity.foundation/ecdh-1pu-implementation/ | Post | Implementation | 2021-09-21 | |||||||||||||||||||||||||||||||
| 550 | DIDComm | Jolocom | Community matters: Jolocom’s latest contributions to DIF | We at Jolocom strongly believe that DIDComm is a crucial infrastructure element for the broader and future-proof SSI stack, and [current work on DIDComm v2 includes Jolocom’s implementation of the specification](http://github.com/jolocom/didcomm-rs) with authcrypt (authenticated encrypted) and most of the low level of the protocol. | ...Interested parties can already start building high-level verifiable credential-based services and workflows on the Rust KERI implementation. | https://jolocom.io/blog/jolocoms-contributions-to-dif/ | https://jolocom.io/wp-content/uploads/2020/05/Jolocom-Logbook-DIF-contribution-cover-02-alt.jpg | Post | Implementation | 2021-01-19 | ||||||||||||||||||||||||||||||
| 551 | mDL | INATBA | “Decentralised Identity: What’s at Stake?” | Looking at the above comparison, It is clear that both approaches strive to maintain user control of their personal data, selective disclosure/data minimization, and cryptographic methods to prove the integrity of identity claims. The differences are: first in their reliance (mDL) or independence (SSI) from issuer involvement in verification interactions, and second in their cryptographic approach, where the mDL relies on externally provided cryptographic tools while SSI builds on holder controlled private keys | ← earlier paper | https://inatba.org/wp-content/uploads/2020/11/2020-11-INATBA-Decentralised-Identity-001.pdf | Post | Intro | 2021-11 | |||||||||||||||||||||||||||||||
| 552 | mDL | SpruceID | An Identity Wallet Bill of Rights - Starting With the Mobile Driver License | Spruce’s continued mission is to let users control their data across the web, whether it’s web2, web3, or beyond. This also applies to credentials issued by existing entities, such as the Mobile Driver License (mDL) issued by motor vehicle authorities across the world. | Spruce’s continued mission is to let users control their data across the web, whether it’s web2, web3, or beyond. This also applies to credentials issued by existing entities, such as the Mobile Driver License (mDL) issued by motor vehicle authorities across the world. | https://blog.spruceid.com/an-identity-wallet-bill-of-rights/ | Post | Intro | 2022-09-12 | |||||||||||||||||||||||||||||||
| 553 | mDL | INATBA | Mobile Driver’s Licence (mDL) VS. Self-Sovereign Identity (SSI) | The ISO mDL specification (ISO-compliant Driving License or IDL) is purpose driven, as its name implies, but is said to be specifically intended to:<br>* enable verifiers not affiliated with or associated with the issuing authority to gain access to and authenticate the information<br>* allow the holder of the driving license to decide what information to release to a verifier<br>* include the ability to update information frequently, and to authenticate information at a high level of confidence. | https://inatba.org/identity/mobile-drivers-licence-mdl-self-sovereign-identity-ssi-comparison/ | Post | Main | 2020-11 | ||||||||||||||||||||||||||||||||
| 554 | mDL | CCG Mailing List | https://w3c-ccg.github.io/vdl-test-suite/ | Manu Sporny | Spruce, MATTR, Digital Bazaar, | Verifiable Driver's Licenses and ISO-18013-5 (mDL) | As some of you might be aware, ISO-18013-5 (mDL -- Mobile Driver's License) was published as a global ISO standard in September 2021. A number of us in the W3C CCG and W3C VCWG attempted to ensure that W3C Verifiable Credentials were supported by the mDL work, but that effort is not reflected in the finalized ISO mDL standard (and due to the way ISO operates, we are not at liberty to share any details). There have been increasing concerns related to the divergence of mDL with W3C Verifiable Credentials and to the market dynamics at play around mDL. | https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html | Discussion | Main | 2021-11-29 | |||||||||||||||||||||||||||||
| 555 | mDL | Procivis | ISO/IEC 18013-5 vs Self-Sovereign Identity: A proposal for an mDL Verifiable Credential | in the context of government identity programs we see it as useful to compare them on the following parameters – background, credential data model & trust anchor and transmission protocols. | https://www.procivis.ch/post/iso-iec-18013-5-vs-self-sovereign-identity-a-proposal-for-an-mdl-verifiable-credential | https://uploads-ssl.webflow.com/5fae427844470c4d4b49d62b/62440e2a85213a51704c8641_Picture%203.png | Post | Main | 2022-03-30 | |||||||||||||||||||||||||||||||
| 556 | mDL | AAMVA | Mobile Driver's License (mDL) Implementation Guidelines 1.2 | The AAMVA Joint Mobile Driver’s License (mDL) Working Group (WG) has been active around mobile identification since 2012. As the mDL evolves, the mDL WG continues to identify and address topics on which guidance to Issuing Authorities can be helpful. This document represents the bulk of the current guidance, and points to additional resources as needed | https://www.aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation-Guidelines-Version-1-2_final.pdf | Report | Main | 2023-01 | ||||||||||||||||||||||||||||||||
| 557 | mDL | AAMVA | Mobile Driver's License Model Legislation | The Mobile Driver’s License (mDL) Model Legislation has been developed to facilitate the uniformity of proposed legislative changes related to implementation of mDL in various jurisdictions. The model legislation is meant to demonstrate how the requirements in the ISO standards and AAMVA Mobile Driver’s License Implementation Guidelines could be represented in jurisdiction-specific legislation. Thus, the language contained in the model legislation is designed to offer examples and is not expected to be proposed to legislatures without consideration for controlling legal provisions in your jurisdiction | https://www.aamva.org/getmedia/cb9fd6c7-29e6-48a4-926b-e16d6400eab5/mDL-Model-Legislation_final.pdf | Report | Main | 2023-01 | ||||||||||||||||||||||||||||||||
| 558 | mDL | Kantara Initiative | Working Group for Privacy Enhancing Mobile Credentials | Clearly the use of a driver’s license goes well beyond proving eligibility to drive a vehicle. It has become the de-facto standard for proving that you are who you say you are – and are entitled to the product or service requested. An increasing number of states are adopting mobile ID systems to recognise and verify mobile credentials including driver’s licenses (mDL). | https://kantarainitiative.org/introducing-kantaras-working-group-for-privacy-enhancing-mobile-credentials/ | Post | Guidance | 2021-11-15 | ||||||||||||||||||||||||||||||||
| 559 | mDL | Kantara Initiative | Kantara Releases Report on Identity and Privacy Protection For mobile Driver’s Licenses | The report outlines how to implement mDL systems as Privacy Enhancing Technologies. It provides guidance on protecting people’s individual privacy and the digital identifiers of an individual who carries or uses an mDL. | https://kantarainitiative.org/kantara-releases-report-on-identity-and-privacy-protection-for-mobile-drivers-licenses/ | Post | Guidance | 2021-08-27 | ||||||||||||||||||||||||||||||||
| 560 | mDL | Biometric Update | https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/ | Kantara lays out trust-building recommendations for mDLs | A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and their biometric identifiers. | Trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and their biometric identifiers. | https://www.biometricupdate.com/202108/kantara-lays-out-trust-building-recommendations-for-mdls | Post | Guidance | 2021-08-27 | ||||||||||||||||||||||||||||||
| 561 | mDL | CCG | Verifiable Driver's License Interoperability Report 1.0 | The purpose of this test suite is to demonstrate a path to interoperability between the ISO-18013-5 Mobile Driver's License data model and the W3C Verifiable Credentials ecosystem. The technologies explored in this test suite are experimental and meant to be complementary to ISO-18013-5 (mDL) and not a replacement of the standard. This document contains the most recent interoperability report between issuers and verifiers for Verifiable Driver's License Credentials using the Verifiable Driver's License Vocabulary. This report is generated on a weekly basis. | https://w3c-ccg.github.io/vdl-test-suite/ | Report | Guidance | 2023-01-08 | ||||||||||||||||||||||||||||||||
| 562 | mDL | IETF | RFC 8943 | RFC 8943: Concise Binary Object Representation (CBOR) Tags for Date | In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined. | The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. | https://www.rfc-editor.org/rfc/rfc8943 | rfc | CBOR | 2020-11 | ||||||||||||||||||||||||||||||
| 563 | mDL | Personal | https://www.rfc-editor.org/rfc/rfc8943 | Mike Jones | Concise Binary Object Representation (CBOR) Tags for Date is now RFC 8943 | The Concise Binary Object Representation (CBOR) Tags for Date specification has now been published as RFC 8943. In particular, the full-date tag requested for use by the ISO Mobile Driver’s License specification in the ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification†working group has been created by this RFC. The abstract of the RFC is: | Mike Jones shares that CBOR (Concise Binary Object Representation) is officially a specification at IETF. woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it). | https://self-issued.info/?p=2136 | Post | CBOR | 2020-11-20 | |||||||||||||||||||||||||||||
| 564 | Exchange Protocols | IDCommons | https://docs.google.com/document/d/1_b5MxzUPWzYxXxWt7Tw6-MySqh77ZvYHBnUgEBCFH7Q/edit | Kaliya Young, Orie Steele, Drummond, Kyle, et al. | Figuring out Verifiable Credentials Exchange - combining Bloom, Aires Protocols, Presentation Exchange into a unified - Killer Whale Jello Salad | Important parts of the protocol - what format you want is in an attachment.<br>You can provide multiple attachments - request things in multiple formats<br>You have the option of responding in different formats.<br>Messages - that go back and forth and messages that respond with different formats. | https://iiw.idcommons.net/22H/_Figuring_out_Verifiable_Credentials_Exchange_-_combining_Bloom,_Aires_Protocols,_Presentation_Exchange_into_a_unified_-_Killer_Whale_Jello_Salad | Session Notes | Background | 2021-05-06 | ||||||||||||||||||||||||||||||
| 565 | Exchange Protocols | IDCommons | https://iiw.animo.id | BBS+ Credential Exchange in Hyperledger Aries | 19:18:25 From Sebastian Schmittner : Is there some working implementation out there to actually generate/work with these VCs shown currently?<br>19:18:58 From Troy Ronda : aries-framework-go is one of them.<br>19:19:24 From Karim Stekelenburg : The ACA-Py implementation will be merged in shortly<br>19:20:50 From Stephen Curran : PR: https://github.com/hyperledger/aries-cloudagent-python/pull/1061<br>19:22:02 From Sebastian Schmittner : awesome! We are doing some prototyping right now where we are using JSON-LD VCs with the americans, but, since we are also running a node in the HL Indy network of ID Union, it would be really great if we could bridge the Ocean here ;) | https://iiw.idcommons.net/11E/_BBS+_Credential_Exchange_in_Hyperledger_Aries | Session Notes | Background | 2021-05-06 | |||||||||||||||||||||||||||||||
| 566 | Exchange Protocols | IDCommons | Credentials Exchange - figuring it out - (Jello Bowl Death Match?) | The ultimate goal is to get to a clear exchange protocols.<br><br>Also to have a paper similar to [this one](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf) that outlines the choice landscape that is and points to a convergence point<br><br>Good Health Pass is literally right now trying to figure this out and will “pick” solutions it needs to get implementations working in the next 30-90 days and point the whole industry in one direction.<br><br>We started out with this framework of understanding<br><br>Contextualizing VC Exchange in Layers<br><br>Verifiable Credentials (VC or VCs) is one of the key standardized components of decentralized identity. [The VCs Data Model](https://www.w3.org/TR/vc-data-model/), defined at the W3C, is a universal data format that lets any entity express anything about another entity. It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy-respecting, and machine-verifiable.<br><br>There clarity emerging on standards that are interoperable with one another for the VC format.<br><br>There is less clarity on the Exchange mechanisms.<br><br>One way that has been proposed to look at the exchange options available is to see them in different layers. | https://iiw.idcommons.net/12F/_Credentials_Exchange_-_figuring_it_out_-_(Jello_Bowl_Death_Match%3F)_%E2%80%93 | Session Notes | Background | DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange | 2021-05-06 | |||||||||||||||||||||||||||||||
| 567 | Exchange Protocols | CCG | Manu Sporny | chapi.io launches, includes VC playground | TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser. | https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html | Discussion | CHAPI | 2022-06-27 | |||||||||||||||||||||||||||||||
| 568 | Exchange Protocols | TrustBloc | TrustBloc - Duty Free Shop use case (CHAPI Save + WACI Share) | This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential through CHAPI and Share the Verifiable Credential/Presentation through WACI. | TrustBloc is an Open Source platform to build Digital Identity solutions. This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential... | https://www.youtube.com/watch?v=aagFJBI1fBE | https://i.ytimg.com/vi/aagFJBI1fBE/maxresdefault.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AHUBoAC4AOKAgwIABABGGAgTihlMA8=&rs=AOn4CLC_JUslbXvHG_E-z0e2u2iUa9Eu5A | Video | CHAPI | 2021-10-12 | ||||||||||||||||||||||||||||||
| 569 | Exchange Protocols | CCG Mailing List | Joe Andrieu | VC-API Diagram for today. Focus on CHAPI | We'll be discussing this on today's call. | https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0007.html | https://i.imgur.com/s1C2lA8.png | Discussion | CHAPI | 2021-11-02 | ||||||||||||||||||||||||||||||
| 570 | Exchange Protocols | CCG Mailing List | Manu Sporny | chapi.io launches, includes VC playground | TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser. | https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html | Discussion | CHAPI | 2022-06-27 | |||||||||||||||||||||||||||||||
| 571 | Exchange Protocols | CCG Mailing List | https://playground.chapi.io/issuer | Manu Sporny | chapi.io playground upgrades - credential selector, resident card | The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue. [...] We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary [...] You can try both of these new features out in the playground | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0111.html | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/att-0111/03-chapi-prc-large.png | Discussion | CHAPI | 2022-07-27 | |||||||||||||||||||||||||||||
| 572 | Exchange Protocols | CCG Mailing List | Manu Sporny | Jobs For The Future VC added to chapi.io playground | TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached. | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0031.html | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/att-0031/chapi.io-jff-1.png | Discussion | CHAPI | 2022-07-13 | ||||||||||||||||||||||||||||||
| 573 | Exchange Protocols | CCG | https://github.com/w3c-ccg/vc-api/ | Verifiable Credentials API v0.3 | The W3C Credentials Community Group Verifiable Credential APIs are a set of RESTful API definitions conforming with the OpenAPI 3.0 Specification that support Verifiable Credential Lifecycle Management such as Issuing, Holding/Presentation/Exchange, and Verification for the roles of Issuer, Holder, and Verifier as described in the Verifiable Credential Data Model specification. | https://w3c-ccg.github.io/vc-api/ | https://w3c-ccg.github.io/vc-api/diagrams/components.svg | Specification | VC Api | 2023-04-20 | ||||||||||||||||||||||||||||||
| 574 | Exchange Protocols | CCG | Test Interoperability Report for Verifiable Credentials API Issuer | This is a test suite to demonstrate interoperability of issuers using the VC HTTP API. | https://w3c-ccg.github.io/vc-api-issuer-test-suite/ | Report | VC Api | 2023-05-28 | ||||||||||||||||||||||||||||||||
| 575 | Exchange Protocols | CCG | VC API Verifier Interoperability Report 1.0 | This test suite demonstrates the interoperability of verifiers using the VC HTTP API. | https://w3c-ccg.github.io/vc-api-verifier-test-suite/ | Report | VC Api | 2023-05-28 | ||||||||||||||||||||||||||||||||
| 576 | Exchange Protocols | CCG | Ed25519Signature 2020 Interoperability Report 1.0 | The purpose of this test suite is to demonstrate a path to interoperability for the Ed25519 Signature 2020. The technologies explored in this test suite are experimental. This document contains the most recent interoperability report for Ed25519 Signature 2020. | https://w3c-ccg.github.io/di-ed25519-test-suite/ | Report | VC Api | 2023-05-28 | ||||||||||||||||||||||||||||||||
| 577 | Exchange Protocols | CCG | Status List 2021 Interoperability Report 1.0 | The purpose of this test suite is to demonstrate a path to interoperability for StatusList2021 . | https://w3c-ccg.github.io/status-list-2021-test-suite/ | Report | VC Api | 2023-05-28 | ||||||||||||||||||||||||||||||||
| 578 | Exchange Protocols | IDCommons | https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/ | Dmitri Zagidulin | IIW | 13E/ VC-HTTP-API discussion -FAQ, vs other APIs, etc- | We are going to go through the API and address the challenges... currently only have a YAML file and missing a lot of other documentation. We are going to address these issues with the goal of concrete proposals the community can provide feedback on. | https://iiw.idcommons.net/13E/_VC-HTTP-API_discussion_-FAQ,_vs_other_APIs,_etc- | Session Notes | VC Api | 2023-05-21 | |||||||||||||||||||||||||||||
| 579 | Exchange Protocols | CCG | VC HTTP API Special Topic Call | - VC HTTP API Proposals Under Consideration<br>- Use Cases Document<br>- Scope of VC HTTP API<br>- VC HTTP API Specification Structure | https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/ | minutes | VC Api | 2021-04-22 | ||||||||||||||||||||||||||||||||
| 580 | Exchange Protocols | DIF | Bloom | Wallet And Credential Interactions | There are interactions between a wallet and relying party that require passing information between the two. WACI provides a standard for these interactions. | https://identity.foundation/wallet-and-credential-interactions/ | https://identity.foundation/wallet-and-credential-interactions/resources/qr.png | Specification | WACI | 2022-03-16 | https://github.com/decentralized-identity/wallet-and-credential-interactions | |||||||||||||||||||||||||||||
| 581 | Exchange Protocols | Bloom | https://iiw.idcommons.net/4K/_Introducing:_WACI_(Wallet_And_Credential_Interaction) | IIW32 | Bloom donates WACI to the Decentralized Identity Foundation (DIF) | WACI was introduced at the annual IIW32 Workshop with a very warm response. Its goal is to specify how interactions between a wallet and Relying Party (RP) such as an issuer or a verifier happen. At its core, WACI is a handshake of JWTs, where the RP signs a JWT that is given to the wallet, and the wallet signs another JWT containing the initial token as a "challenge" claim. This allows the wallet to prove ownership of its DID.<br><br>The easiest way to see the benefit of WACI is to offer a way to log into an application without a password with Verified Credential (VC) based authentication that cannot be faked. | https://bloom.co/blog/waci-donation/ | Post | WACI | 2021-06-21 | ||||||||||||||||||||||||||||||
| 582 | Exchange Protocols | DIF | https://github.com/decentralized-identity/waci-didcomm | Wallet And Credential Interactions for DIDComm | This document describes an interoperability profile which incorporates elements from a number of existing specifications and protocols, without assuming or requiring an implementer to understand all of them. It inherits its overall structure from the current pre-draft of WACI, but makes use of elements from the DIDComm v2.0 messaging protocol, along with Aries Present Proof message formats and DIF Presentation Exchange data objects. This version of the specification also restricts itself to Verifiable Credentials that make use of the JsonWebSignature2020 signature suite and Ed25519Signature2018 signature suite. | https://identity.foundation/waci-didcomm/ | https://identity.foundation/waci-didcomm/resources/swimlanes_io_d_C5HnpvA4f.png | Specification | WACI | 2023-01-16 | https://github.com/decentralized-identity/waci-didcomm | |||||||||||||||||||||||||||||
| 583 | Exchange Protocols | DIF | https://identity.foundation/presentation-exchange/ | Presentation Exchange | A common activity between peers in identity systems that feature the ability to generate self-asserted and third-party issued Claims is the demand and submission of proofs from a Holder to a Verifier. This flow implicitly requires the Holder and Verifier have a mechanism to facilitate the two primary steps in a proving exchange: a way for Verifiers to describe proof requirements, and for Holders to describe submissions of proof which align with those requirements. | https://identity.foundation/presentation-exchange/ | Specification | Message Format | 2023-03-31 | https://github.com/decentralized-identity/presentation-exchange | ||||||||||||||||||||||||||||||
| 584 | Exchange Protocols | DIF | Credential Manifest | For User Agents (e.g. wallets) and other service that wish to engage with Issuers to acquire credentials, there must exist a mechanism for negotiating (via services and interfaces that are out of scope) what inputs are required from a Subject to process a request for credential(s) issuance. The Credential Manifest is a common data format for describing the inputs a Subject must provide to an Issuer for subsequent evaluation and issuance of the credential(s) indicated in the Credential Manifest, i.e. for a Subject to become a Holder. | https://identity.foundation/credential-manifest/ | Specification | Editor’s Draft | Message Format | 2023-05-04 | https://github.com/decentralized-identity/credential-manifest | ||||||||||||||||||||||||||||||
| 585 | Exchange Protocols | Hyperledger | Negotiate Proof | After an issuer has completed the "Save Schema and Cred Def" and "Issue Credential" how-tos, you have all the context for a credential holder and a relying party (verifier) to generate a zero-knowledge proof based on the credential. | https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/how-tos/negotiate-proof/README.html | https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/_images/3-phases.png | docs | Assorted | 2018 | |||||||||||||||||||||||||||||||
| 586 | Exchange Protocols | Hyperledger | Aries RFC 0023: DID Exchange Protocol 1.0 | This RFC describes the protocol to exchange DIDs between agents when establishing a DID based relationship.<br><br>Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs. | https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md | rfc | Assorted | 2021-04-15 | ||||||||||||||||||||||||||||||||
| 587 | Exchange Protocols | IDCommons | Paul Knowles | IIW | Dynamic Data Sharing Hub: A target component for criteria searches on distributed structured data | Dynamic Data Economy is a roadmap towards fair, decentralized and authentic data economy. Many times people are referring to blockchain technology as a revolution within digital space. But often they actually mean something more profound: the promise of Decentralisation brought by blockchain. A Dynamic Data Economy brings decentralization outside the technology realm into digital solutions for any economic actors. It does so by decentralizing all layers of the ecosystem: | https://iiw.idcommons.net/10L/_Dynamic_Data_Economy:_Digital_Identity,_Authentic_Data_Flows,_Data_Mesh_and_other_dragons | Session Notes | Assorted | 2021-05-07 | ||||||||||||||||||||||||||||||
| 588 | Exchange Protocols | SSI Orbit | #6 - The Importance of Data Inputs and Semantics for SSI with Paul Knowles from Human Colossus Foundation | In terms of decentralized data initiatives, Paul is the innovation lead behind the Master Mouse Model (MMM), a conceptual model for a Dynamic Data Economy (DDE) – a safe and secure data sharing economy. He is also the inventor of the Overlays Capture Architecture (OCA) and the main spearhead behind the Blinding Identity Taxonomy (BIT), both of which facilitate a unified data language so that harmonized data can be utilized by dynamic data sharing hubs for improved data science, statistics, analytics and other meaningful services. | In today’s episode, I talk about the importance of data inputs and semantics with joined by Paul Knowles, an individual who defines himself as a semantic nerd. | https://podcasters.spotify.com/pod/show/ssi-orbit-podcast/episodes/6---The-Importance-of-Data-Inputs-and-Semantics-for-SSI-with-Paul-Knowles-from-Human-Colossus-Foundation-etvm5p | episode | Assorted | 2023-05-17 | |||||||||||||||||||||||||||||||
| 589 | Exchange Protocols | Human Colossus Foundation | Dynamic Data Sharing Hub - DDSH - Patient Recruitment Use Case | Purpose-based Service Providers<br>• A company's "why" is a collective sense of purpose that reflects the company's merit, trustworthiness, and authenticity. It is the feeling the company wants their customers to experience when they engage with proprietary products and services – the identity that their customers want to align with.<br>• Establishing authentic communication channels in a peer-to-peer networking environment provides the basis to initiate transaction flows for consented data capture and data sharing between an organisation and the data subject (or a delegate/guardian acting on behalf of the data subject).<br>• The initial point of new data entry into a decentralised data ecosystem.<br><br>Insight Based Service Providers<br>• The value of data insights is not only to learn and enable validated decision-making, but also to make everybody in the company’s ecosystem ‘move’ in the same direction. As today’s world is volatile, uncertain, complex and ambiguous, insights need to be generated continuously rather than once in a while.<br>• Data insights gained from analysing sets of information that pertain to a given topic (or situation) enables businesses to make better-informed decisions, reducing the risk that comes with trial-and-error testing methods. Semantic harmonisation enables criteria searches on structured data from multiple sources, providing the basis to initiate a transaction flow for consented data access between the requesting party and the data governance authority (acting on behalf of consenting data subjects).<br>• Searching for existing data in a decentralised data ecosystem. | https://drive.google.com/file/d/1TSfpysHy-UN9GnAiNPB81ZgGQaFCFcjo/view?usp=sharing | Presentation | Assorted | 2023-05-18 | ||||||||||||||||||||||||||||||||
| 590 | OpenID Connect | OpenID | OpenID Connect | OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. | https://openid.net/connect/ | https://openid.net/wp-content/uploads/2023/05/openid-connect-digram-red.png | page | Main | 2014-02-04 | |||||||||||||||||||||||||||||||
| 591 | OpenID Connect | OpenID | Frequently Asked Questions | OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure verifiable, answer to the question: “What is the identity of the person currently using the browser or native app that is connected to me?” | https://openid.net/connect/faq/ | faq | Main | 2014-02-20 | ||||||||||||||||||||||||||||||||
| 592 | OpenID Connect | OpenID | OpenID Certification Program | OpenID Certified markThe OpenID Foundation enables deployments of OpenID Connect and the Financial-grade API (FAPI) Read/Write Profile to be certified to specific conformance profiles to promote interoperability among implementations. The OpenID Foundation’s certification process utilizes self-certification and conformance test suites developed by the Foundation. Certified implementations can use the “OpenID Certified” certification mark. | https://openid.net/certification/ | page | Main | 2015-02-18 | ||||||||||||||||||||||||||||||||
| 593 | OpenID Connect | Personal | Kim D Hamilton | I've read every decentralized identity protocol so you don't have to | They all just read like "nothing to see here, just f- right off" Oh, except for OIDC Credential Provider. Well done to them! | https://twitter.com/kimdhamilton/status/1397241823190523904 | tweet | About | 2021-05-25 | |||||||||||||||||||||||||||||||
| 594 | OpenID Connect | Self Issued | Mike Jones | OpenID Connect Presentation at IIW XXXII | If you have an Android phone or log in at Apple, AOL, Deutsche Telekom, Google, KDDI, Microsoft, NEC, NTT, Salesforce, Softbank, Symantec, Verizon, or Yahoo! Japan, you’re already using OpenID Connect – Many other sites and apps large and small also use OpenID Connect | * Introduction to OpenID Connect [(PowerPoint)](https://self-issued.info/presentations/OpenID_Connect_Introduction_12-Oct-21.pptx) [(PDF)](https://self-issued.info/presentations/OpenID_Connect_Introduction_12-Oct-21.pdf)<br><br>The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect. | https://self-issued.info/?p=2167 | Presentation | About | 2021-04-21 | ||||||||||||||||||||||||||||||
| 595 | OpenID Connect | Self Issued | Mike Jones | OpenID Presentations at December 2021 OpenID Virtual Workshop | * OpenID Connect Working Group [(PowerPoint)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_9-Dec-21.pptx) [(PDF)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_9-Dec-21.pdf)<br>* OpenID Enhanced Authentication Profile (EAP) Working Group [(PowerPoint)](http://self-issued.info/presentations/OpenID_EAP_Working_Group_9-Dec-21.pptx) [(PDF)](http://self-issued.info/presentations/OpenID_EAP_Working_Group_9-Dec-21.pdf)<br><br>use of IETF Token Binding specifications with OpenID Connect and integration with FIDO relying parties and/or other strong authentication technologies.” | https://self-issued.info/?p=2214 | Presentation | About | 2021-12-09 | |||||||||||||||||||||||||||||||
| 596 | OpenID Connect | Ubisecure | Francesca Hobson | Let’s talk about digital identity with Oscar Santolalla, Nat Sakimura and Petteri Stenius | the history of OpenID Connect and how it became so prevalent, with special guests [Nat Sakimura](https://www.linkedin.com/in/natsakimura/), Chairman at the OpenID Foundation, and [Petteri Stenius](https://www.linkedin.com/in/petteri-stenius-6a637/), Principal Scientist at Ubisecure. [...] “New technology seldomly completely replaces the older technologies. They will form additional layers, and slowly start replacing it.” | Oscar explores the history of OpenID Connect and how it became so prevalent, with special guests Nat Sakimura and Petteri Stenius. | https://www.ubisecure.com/podcast/openid-connect/ | episode | About | 2021-11-03 | ||||||||||||||||||||||||||||||
| 597 | OpenID Connect | Ubisecure | Petteri Stenius | Differences between SAML, OAuth & OIDC (OpenID Connect) | This article is an update to the popular Difference between SAML and OAuth blog post we published in 2017. This blog expands to cover OpenID Connect (OIDC) vs OAuth 2.0 vs SAML 2.0 (Security Assertion Markup Language). | OpenID Connect (OIDC) vs OAuth 2.0 vs SAML. Learn the technical differences between the protocols. Help determine the most suitable protocol for your requirements. | https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/ | Post | About | 2020-08-10 | ||||||||||||||||||||||||||||||
| 598 | OpenID Connect | Identiverse | Preeti Rastogi, Nat Sakimura | Identiverse | Distributed Open Identity: Self-Sovereign OpenID: A Status Report | This session will provide an overview of the development since then and brings the audience up-to-speed on what is happening in the space including Demo of such implementations. It is a follow up of the Identiverse 2019 session “SSO: Self-sovereign OpenID Connect – a ToDo list”. | https://identiverse.gallery.video/detail/videos/standards/video/6184823227001/distributed-open-identity:-self-sovereign-openid:-a-status-report?autoStart=true | Video | About | 2020-08-26 | ||||||||||||||||||||||||||||||
| 599 | OpenID Connect | OpenID Japan | OpenID | Personal Digital Transformation and Holistic Digital Identity | from the OpenID Summit Tokyo 2020 Keynote […] about Claims, Identity, Self-ness, Who-ness, and OpenID Connect and Decentralized Identity. | This probably is the last speech that Kim Cameron, the author of the Laws of Identity, gave in front of a large audience in person. It is from the OpenID Sum... | https://www.youtube.com/watch?v=9DExNTY3QAk | https://i.ytimg.com/vi/9DExNTY3QAk/hqdefault.jpg | Video | About | 2021-12-03 | |||||||||||||||||||||||||||||
| 600 | OpenID Connect | personal | Nat Sakimura | Announcing GAIN: Global Assured Identity Network | All business entities in the network are vetted as part of the creation and maintenance of their business accounts at their hosting organization, and they cannot remain anonymous. They will be accountable. As a result, the consumer has the assurance that they will be safe to transact with them—meaning more business for the Relying Parties. All of the good actors benefit. | One key benefit of the approach proposed in the white paper is that the standards required to enable this network already exist: OpenID Connect and eKYC/IDA. | https://nat.sakimura.org/2021/09/14/announcing-gain/ | Post | Organization | 2021-09-14 | ||||||||||||||||||||||||||||||
| 601 | OpenID Connect | DIF | DIF and OIDF cooperation | to work together on areas of mutual interest, allowing working groups to align and coordinate through dual-members. The first major collaboration, which has already been underway for weeks, is a process for revising the Self-Issued OpenID Connect (SIOP) chapter of the OpenID Connect (OIDC) specification | DIF is proud to announce that it has entered into a liaison agreement with the OpenID Foundation (OIDF). This provides a mechanism for both parties to work together on areas of mutual interest… | https://medium.com/decentralized-identity/dif-oidf-9753b9bd0093 | Post | Organization | 2020-11-09 | |||||||||||||||||||||||||||||||
| 602 | OpenID Connect | OpenID | ABConnectWG | A/B Connect Working Group | OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly. OpenID Connect can also be extended to include more robust mechanisms for signing and encryption. Integration of OAuth 1.0a and OpenID 2.0 required an extension (called the OpenID/OAuth hybrid); in OpenID Connect, OAuth 2.0 capability is built into the protocol itself. | https://openid.net/wg/connect/ | Working Group | Working Group | 2015-02-18 | |||||||||||||||||||||||||||||||
| 603 | OpenID Connect | OpenID | ABConnectWG | Certified OpenID Connect Implementations Featured for Developers | OpenID Certified markThe following OpenID Connect Implementations have attained OpenID Certification for one or more certification profiles, including an authentication profile. Their certifications are listed at https://openid.net/certification/. | https://openid.net/developers/certified/ | page | Working Group | 2017-02-11 | |||||||||||||||||||||||||||||||
| 604 | OpenID Connect | OpenID | ABConnectWG | First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved | - Self-Issued OpenID Provider v2<br>- OpenID Connect for Verifiable Presentations<br>An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. These are the first Implementer’s Drafts of these specifications. These specifications are products of the OpenID Connect Working group | https://openid.net/2022/02/08/first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications-approved/ | Post | Working Group | 2022-02-08 | |||||||||||||||||||||||||||||||
| 605 | OpenID Connect | OpenID | ABConnectWG | Rodriguez Fernandez | OpenID Connect Client-Initiated Backchannel Authentication Flow – Core 1.0 | OpenID Connect Client Initiated Backchannel Authentication Flow is an authentication flow like OpenID Connect. However, unlike OpenID Connect, there is direct Relying Party to OpenID Provider communication without redirects through the user's browser. This specification has the concept of a Consumption Device (on which the user interacts with the Relying Party) and an Authentication Device (on which the user authenticates with the OpenID Provider and grants consent). This specification allows a Relying Party that has an identifier for a user to obtain tokens from the OpenID Provider. The user starts the flow with the Relying Party at the Consumption Device, but authenticates and grants consent on the Authentication Device | https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html | Specification | Working Group | 2021-08-01 | ||||||||||||||||||||||||||||||
| 606 | OpenID Connect | OpenID | ABConnectWG | Oliver Terbu | OpenID Connect for Verifiable Presentations | This specification defines an extension of OpenID Connect to allow presentation of claims in the form of W3C Verifiable Credentials as part of the protocol flow in addition to claims provided in the id_token and/or via UserInfo responses. | https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-08.html | Specification | Working Group | 2022-01-28 | ||||||||||||||||||||||||||||||
| 607 | OpenID Connect | OpenID | ABConnectWG | Kristina Yasuda | Self-Issued OpenID Provider v2 | This specification extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User's local control. End-Users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the RPs. This allows users to interact with RPs directly, without relying on third-party providers or requiring the End-User to operate their own hosted OP infrastructure. | https://openid.net/specs/openid-connect-self-issued-v2-1_0-07.html | Specification | Working Group | 2022-01-28 | ||||||||||||||||||||||||||||||
| 608 | OpenID Connect | OpenID | ABConnectWG | OpenID Connect for Identity Assurance 1.0 | This specification defines an extension to OpenID Connect [OpenID] for providing Relying Parties with identity information, i.e., Verified Claims, along with an explicit statement about the verification status of these Claims (what, how, when, according to what rules, using what evidence). This specification is aimed at enabling use cases requiring strong assurance, for example, to comply with regulatory requirements such as Anti-Money Laundering laws or access to health data, risk mitigation, or fraud prevention. | https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html | Specification | Working Group | 2022-08-19 | |||||||||||||||||||||||||||||||
| 609 | OpenID Connect | OpenID | ABConnectWG | OpenID Connect for Identity Assurance – Overview & Call to Action | OpenID Connect for Identity Assurance is primarily focussed on addressing use-cases where the details of the assurance process used to verify and validate the end-users identity need to be explicitly communicated.<br><br>The working group believes it’s a good fit for account opening, staff on-boarding, account recovery and access to restricted services where communication of how the underlying identity was established is needed. | https://openid.net/oidc4ida-overview-call-to-action/ | Post | Working Group | 2022-08-25 | |||||||||||||||||||||||||||||||
| 610 | OpenID Connect | OpenID | ABConnectWG | OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 | This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators. | https://openid.net/specs/openid-connect-eap-acr-values-1_0-01.html | Specification | Working Group | 2021-10-03 | |||||||||||||||||||||||||||||||
| 611 | OpenID Connect | Self Issued | Mike Jones | The OpenID Connect Logout specifications are now Final Specifications | The OpenID Connect Logout specifications are now Final Specifications<br>Thanks to all who helped us reach this important milestone! This was originally [announced on the OpenID blog](https://openid.net/2022/09/12/the-openid-connect-logout-specifications-are-now-final-specifications/). | https://self-issued.info/?p=2298 | Post | Working Group | 2022-09-27 | |||||||||||||||||||||||||||||||
| 612 | OpenID Connect | IDCommons | Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker | IIW | Use-cases: OIDC for Verifiable Credentials - How do you want to use Identity Provider you control? | We talk about users controlling their own identities, but what does it really mean in “real-life”?<br><br>For example, in OpenID Connect, what are the real-life use-cases and concrete needs to move from Identity Providers offered by Identity Companies to users controlling their own Identity Provider | https://iiw.idcommons.net/12G/_Use-cases:_OIDC_for_Verifiable_Credentials_-_How_do_you_want_to_use_Identity_Provider_you_control%3F | Session Notes | Verifiable Credentials | 2021-05-07 | ||||||||||||||||||||||||||||||
| 613 | OpenID Connect | IDCommons | https://www.slideshare.net/TorstenLodderstedt/openid-connect-for-w3c-verifiable-credential-objects | Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker | IIW | OpenID Connect for W3C Verifiable Credential Objects | Have been incubated in OpenID Foundation and DIF’s joint Self-Issued OpenID Provider WG - contact Kristina ([kristina.yasuda@microsoft.com](mailto:kristina.yasuda@microsoft.com) for participation details) | https://iiw.idcommons.net/2F/_OpenID_Connect_for_W3C_Verifiable_Credential_Objects | Session Notes | Verifiable Credentials | 2021-05-06 | |||||||||||||||||||||||||||||
| 614 | OpenID Connect | IDCommons | https://docs.google.com/presentation/d/1w-rmwZoLiFWczJ4chXuxhY0OsgHQmlIimS2TNlce4UU/edit?usp=sharing | Nat Sakimura, Edmund Jay, Kristina Yasuda | IIW | OpenID Connect Claims Aggregation | This session discussed how OIDC Claims Aggregation Draft solves certain problems left open in Connect-Core: 1/ How to get a token from CP is hand-wavy; 2/ No specified method to down scope the userinfo of the CP; 3/ No way to provide a binding information between CP:sub and IdP:sub. | https://iiw.idcommons.net/5B/_OpenID_Connect_Claims_Aggregation | Session Notes | Verifiable Credentials | 2021-05-06 | |||||||||||||||||||||||||||||
| 615 | OpenID Connect | Chakaray | The Era of Self-Sovereign Identity | VC-AuthN OIDC uses the OpenID connect standards to easily integrate with the supported systems and also provides a way to authenticate using the verifiable credentials, giving the control back to the user. This is similar to the traditional OpenID connect, the only difference is in the token information. Rather than using the user’s information to construct the token, this uses claims in the verifiable credentials presented by the user. | Discover how to make digitization more secure and reliable with Self-Sovereign Identity and the reasons why we should switch to it. | https://www.chakray.com/era-self-sovereign-identity/ | Post | Verifiable Credentials | 2020-12-01 | |||||||||||||||||||||||||||||||
| 616 | OpenID Connect | Personal | Pranav Kirtani | How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding | Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding. | https://pranavkirtani.medium.com/how-a-combination-of-federated-identity-and-verifiable-credentials-can-help-with-customer-7e6518feb018 | https://miro.medium.com/v2/resize:fit:1200/0*ENXUBvSdImT5qL_f | Post | Verifiable Credentials | 2021-07-18 | ||||||||||||||||||||||||||||||
| 617 | OpenID Connect | personal | Kristina Yasuda | IIW | SIOP Use-cases - IIW Spring 2021 | * Continuity of a service<br>* Offline Authentication<br>* Speed, reduced latency<br>* Choice, Portability<br>* Privacy | https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit#slide=id.p | Presentation | Verifiable Credentials | 2021 | ||||||||||||||||||||||||||||||
| 618 | OpenID Connect | Sphereon | OIDC with SIOPv2 and DIF Presentation Exchange | I gave the following presentation on the [OpenID Connect Working Group](https://openid.net/wg/connect/) during the [September 13, 2021 OpenID Workshop](https://openid.net/oidf-workshop-at-eic-2021-monday-september-13-2021/) at the [2021 European Identity and Cloud (EIC) conference](https://www.kuppingercole.com/events/eic2021/). As I noted during the talk, this is an exciting time for OpenID Connect; there’s more happening now than at any time since the original OpenID Connect specs were created! | A demo of our implementation of OpenID Connect with SIOPv2 and the DIF Presentation Exchange. | https://vimeo.com/630104529 | https://i.vimeocdn.com/video/1272386756-4e38e1ea6118fd8ea001cdb8650e7a2fe6a135a8768e6af6c | Video | Verifiable Credentials | 2021-10-12 | ||||||||||||||||||||||||||||||
| 619 | OpenID Connect | personal | Phil Windley | Using OpenID4VC for Credential Exchange; Technometria - Issue #62 | Extending OAuth and OIDC to support the issuance and presentation of verifiable credentials provides for richer interactions than merely supporting authentication. All the use cases we’ve identified for verifiable credentials are available in OpenID4VC as well. | Verifiable credentials have transport options other than DIDComm. In this post, I explore the OpenID4VC specification which allows credentials to be used in the OpenID ecosystem. | https://www.windley.com/archives/2022/10/using_openid4vc_for_credential_exchange.shtml | https://www.windley.com/archives/2022/10/openid-log.png | Post | Verifiable Credentials | 2022-10-11 | |||||||||||||||||||||||||||||
| 620 | OpenID Connect | IDCommons | https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit?ts=607b7e5d#slide=id.gd2c45a9dcd_7_21 | Tom Jones | IIW | DID chooser for SIOP | Goal is to allow folks to pick their DID they want to use for a website.<br><br>“Subject choosing which DID to present” | https://iiw.idcommons.net/20A/_DID_chooser_for_SIOP | Session Notes | Verifiable Credentials | 2021-05-06 | |||||||||||||||||||||||||||||
| 621 | OpenID Connect | IDCommons | https://www.slideshare.net/TorstenLodderstedt/openid-connect-4-identity-assurance-at-iiw-32](https://www.slideshare.net/TorstenLodderstedt/openid-connect-4-identity-assurance-at-iiw-32) | Torsten Lodderstedt | IIW | OpenID Connect 4 Identity Assurance | Jacob Dilles proposed to allow RPs to use handles for pre-configured eKYC requests. I filled an issue for discussion by the WG ([https://bitbucket.org/openid/ekyc-ida/issues/1245/pre-configured-claims-ekyc-requests](https://bitbucket.org/openid/ekyc-ida/issues/1245/pre-configured-claims-ekyc-requests). | https://iiw.idcommons.net/10J/_OpenID_Connect_4_Identity_Assurance | Session Notes | Development | 2021-05-06 | |||||||||||||||||||||||||||||
| 622 | OpenID Connect | IDCommons | David Waite | IIW | OpenID Connect: Session Management vs Privacy | To recap:<br>* Front-channel logout is simple<br>* …but brittle and doesn’t give good security guarantees<br>* Back-channel logout is robust<br>* …but difficult to implement/support, can still miss signals<br>* Session Management is useful for some apps<br>* …but is broken in many browsers<br>On their own independent schedules, all browsers have either broken or have plans to break state sharing via cross-site iframes to limit user tracking - arguably making the Session Management approach unusable. | https://iiw.idcommons.net/11M/_OpenID_Connect:_Session_Management_vs_Privacy | Session Notes | Development | 2021-05-06 | ||||||||||||||||||||||||||||||
| 623 | OpenID Connect | Auth0 | Identity, Unlocked... SIOP with Kristina Yasuda | As a discovery mechanism to invoke a Self-Issued OP, the discussion on the podcast covered the usage of a custom schema 'openid://'. Alternative mechanisms to address the limitations of custom schemas are being actively explored in the WG.<br><br>The conversation meanders through deeper details, from how the current [SIOP specification draft](https://bitbucket.org/openid/connect/src/master/openid-connect-self-issued-v2-1_0.md) under the OpenID Foundation picks up the mission from a [former attempt under DIF](https://identity.foundation/did-siop/) to encoding approaches for verifiable presentations (embedding in JWTs, [LD proofs](https://w3c-ccg.github.io/ld-proofs/), how to represent attributes | https://auth0.com/blog/identity-unlocked-explained-season-2-ep-5/ | episode | Development | 2021-03-22 | ||||||||||||||||||||||||||||||||
| 624 | OpenID Connect | SpruceID | https://blog.spruceid.com/sign-in-with-ethereum-decentralizing-an-identity-provider-server/ | Spruce Developer Update #20 | We've set up a [release pipeline](https://github.com/spruceid/ens-oidc/) and had our first witnessed deployment for the ENS Community-Maintained OIDC IdP | https://blog.spruceid.com/spruce-developer-update-20/ | Post | Development | 2022-06-01 | |||||||||||||||||||||||||||||||
| 625 | OpenID Connect | IETF | Sam Goto | Browser APIs to enable OpenID Session Management and Privacy | How does logout in OIDC happen?<br>* Classification problem - browsers do not know it is a logout now<br>* Easiest way<br> * Browser asks for a user consent<br> * Hard from a permission implementation perspective<br> * Tim: No issues with this idea<br> * If user logged into several OPs, user will not look to all the ones they log out from<br>* Option2<br> * Browser classifies signing-in event<br> * On log out does not prompt the user and IdP has no incentives to lie<br> * RPs get to determine if they want to log the user out or not<br> * Whether you can swap generic frame with fenced frame, frame can see it’s own cookies<br> * May not be able to pass any parameters that you need to pass; no link decoration for framed frame<br> * Subdomains also considered, but not well thought out<br> * Logout URL - other option to add, but more work for RP: Resource metadata. Specification - not much adoption. It just feels like a place where RP metadata could be declared which could be useful in this context of the RP defining its metadata (e.g. what IDP it uses) | https://iiw.idcommons.net/13L/_Browser_APIs_to_enable_OpenID_Session_Management_and_Privacy | Session Notes | Development | 2021-05-06 | |||||||||||||||||||||||||||||||
| 626 | KERI | WebofTrust | https://keri.one/keri-resources | KERI One - HomePage | https://keri.one | Main | https://identity.foundation/working-groups/keri.html | https://github.com/WebOfTrust/keri | ||||||||||||||||||||||||||||||||
| 627 | KERI | Blockchain Bird | https://iiw.idcommons.net/3K/_KERI_Q%26A_basic_introduction | IIW32 | KERI Q&A basic introduction | It has lots of relevant links in it to start your journey in KERI.<br><br>What is KERI?<br>* Key Event Receipt Infrastructure<br>* Intends to repair the Internet<br>* KERI = CT with decentralized CA<br>* NOT a coin, token…<br><br>Why KERI? (and not something else)<br>* Strong autonomous identifiers<br>* Abiding to privacy (laws and good habits)<br>* Portability, delegation, rotatable keys<br>* Direct & Indirect method<br>* <there’s more> | https://blockchainbird.org/downloads/KERI-QA-introduction.pdf | Presentation | Main | 2021 | ||||||||||||||||||||||||||||||
| 628 | KERI | personal | Samuel Smith | Key Event Receipt Infrastructure: A Secure Identifier Overlay for the Internet | Secure attribution of any communication to its source<br>Authentic communication<br>Authentic interactions based an secure attribution of all statements by participants<br>Verifiable authenticity of data<br>Data Provenance<br>Authentic data economy | https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_Overview.web.pdf | Presentation | 2.60 | Main | 2021-03-23 | ||||||||||||||||||||||||||||||
| 629 | KERI | https://arxiv.org/abs/1907.02143 | Samuel Smith | KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN | An identity system based secure overlay for the Internet is presented. This includes a primary root-of-trust in self-certifying identifiers. It presents a formalism for Autonomic Identifiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI). The primary root-of-trust are self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key-pair. These are self-contained until/unless control needs to be transferred to a new key-pair. In that event an append only chained key-event log of signed transfer statements provides end verifiable control provenance. This makes intervening operational infrastructure replaceable because the event logs may be therefore be served up by ambient infrastructure. End verifiable logs on ambient infrastructure enables ambient verifiability (verifiable by anyone, anywhere, at anytime). The primary key management operation is key rotation (transference) via a novel key pre-rotation scheme. Two primary trust modalities motivated the design, these are a direct (one-to-one) mode and an indirect (one-to-any) mode. In the direct mode, the identity controller establishes control via verified signatures of the controlling key-pair. The indirect mode extends that trust basis with witnessed key event receipt logs (KERLs) for validating events. The security and accountability guarantees of indirect mode are provided by KERIs Agreement Algorithm for Control Establishment (KACE) among a set of witnesses. | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/KERI_WP_2.x.web.pdf | 2.54 | Main | 2020-10-22 | |||||||||||||||||||||||||||||||
| 630 | KERI | Samuel Smith | Manning | Decentralized key management | ● Why any form of digital key management is hard<br>● Standardsand best practices for conventional key management<br>● The starting point for key management architectures: roots-of-trust<br>● The special challenges of decentralizedkey management<br>● The new tools that verifiable credentials (VCs), decentralized identifiers (DIDs), and self-sovereign identity (SSI) bring to decentralized key management<br>● Key management for ledger-based DID methods<br>● Key management for peer-based DID methods<br>● Fully autonomous decentralized key management with Key Event Receipt Infrastructure (KERI) | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/10-ssi-key-management.pdf | Main | 2020-10-19 | ||||||||||||||||||||||||||||||||
| 631 | KERI | Samuel Smith | UNIVERSAL IDENTIFIER THEORY | Abstract—A universal theory for identifiers is presented. This theory is based on a unified model of identifiers that include cryptographic autonomic identifiers (AIDs) and legitimized (authorized) human meaningful identifiers (LIDs). This model provides truly decentralized trust bases each derived from the cryptographic root-of-trust of a given AID. An AID is based on a self-certifying identifier (SCID) prefix. Self certifying identifiers are not human meaningful but have strong cryptographic properties. The associated self-certifying trust basis gives rise to a trust do- main for associated cryptographically verifiable non-repudiable statements. Every other type of identifier including human meaningful identifiers may then be secured in this resultant trust do- main via an end-verifiable authorization. This authorization legitimizes that human meaningful identifier as an LID though its association with an AID. The result is a secured trust domain specific identifier couplet of aid\|lid. AIDs are provided by the open standard key event receipt infrastructure (KERI). This unified model provides a systematic methodology for the design and implementation of secure decentralized identifier systems that underpin decentralized trust bases and their associated ecosystems of interactions. | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/IdentifierTheory_web.pdf | Main | 2020-10-23 | |||||||||||||||||||||||||||||||||
| 632 | KERI | DIF | KERI Whitepaper | https://raw.githubusercontent.com/decentralized-identity/keri/master/kids/KERI_WP.pdf | Main | 2021-01-11 | ||||||||||||||||||||||||||||||||||
| 633 | KERI | DIF | KERI: For every DID, a microledger | The world of digital identifiers (DIDs) and verifiable credentials (VCs) is evolving quickly, giving much cause for optimism. Standards are starting to connect and move towards functional interoperability, governed by testable protocols. Most of this work is happening on the level of VCs. However, DIDs and their infrastructure are also starting to converge and mature as an extensible-yet-interoperable technology. | https://medium.com/decentralized-identity/keri-for-every-did-a-microledger-f9457fa80d2d | Post | About | 2020-10-19 | ||||||||||||||||||||||||||||||||
| 634 | KERI | personal | https://iiw.idcommons.net/23K/_KERI_Composable_Event_Streaming_Representation | Samuel Smith | KERI Composable Event Streaming Representation | The Three KERI Security Sessions presented at IIW32 have the same set of Slides, it takes 3 hours to get through them.<br><br>This session is slides #190 through #208 | https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_Overview.web.pdf | Presentation | About | 2021-03-04 | ||||||||||||||||||||||||||||||
| 635 | KERI | Harvard | Doc Searls | On KERI: a way not to reveal more personal info than you need to | Here in civilization we typically reveal information about ourselves to others on a need-to-know basis: “I’m over 18.” “I’m a citizen of Canada.” “Here’s my Costco card.” “Hi, I’m Jane.” We may or may not present credentials in these encounters. And in most we don’t say our names. “Michael” being a common name, a guy called “Mike” may tell a barista his name is “Clive” if the guy in front of him just said his name is “Mike.” (My given name is David, a name so common that another David re-branded me Doc. Later I learned that his middle name was David and his first name was Paul. True story.) | https://blogs.harvard.edu/doc/2020/10/22/keri/ | Post | About | 2020-10-22 | |||||||||||||||||||||||||||||||
| 636 | KERI | Jolocom | Jolocom | How KERI tackles the problem of trust | In contrast to blockchain or central registry-based trust systems, KERI is based on a hash-chain data structure called a ‘key event receipt log’ (KERL). Conceptually, it’s similar in some ways to the Peer DID Method specification, except that its data model is a KERL rather than a DID document. And while KERI can be used as a DID method, it is fundamentally not reliant on any of the DID specifications and can be used in many other contexts as well. In particular, it is also useful for Internet of Things (IoT) networks and other security-conscious, low-resource use cases. | https://jolocom.io/blog/how-keri-tackles-the-problem-of-trust/ | Post | About | 2020-10-15 | |||||||||||||||||||||||||||||||
| 637 | KERI | Definitely Identity | Samuel Smith | Tim talks with Sam Smith, creator of KERI | In this episode, we explore the Key Event Receipt Infrastructure (KERI)and how it relates to decentralized identity. We also touch topics in the white paper: trust domains, self-certifying identifiers, architectural implications, and more. | https://podcasts.apple.com/ca/podcast/definitely-identity-episode-14-with-sam-smith/id1496565155?i=1000494102345 | episode | About | 2020-10-08 | |||||||||||||||||||||||||||||||
| 638 | KERI | Human Colossus Foundation | Thinking of DID? KERI On | The current generation of DIDs has introduced an innovative approach to digital identifiers, which has triggered the SSI movement. However, the inclusion of the method space in the DID syntax has led to fragmentation and weak security properties of the identifier type. These known method-space issues give the community impetus to redress them. In light of these innovative developments, now is the time to embrace KERI as an improved interoperable and secure solution for digital identity. | In this blog post, we address DIDs security from the viewpoint of KERI (Key Event Receipt Infrastructure), a novel, simple, and improved DKMS (Decentralized Key Management System) solution for digital identifiers. KERI provides a unifying solution to DID document authentication and resolution that will prove invaluable to use cases where security and interoperability are essential (e.g., for global supply chains and humanitarian applications). | https://humancolossus.foundation/blog/thinking-of-did-keri-on | Post | About | 2021-01-27 | |||||||||||||||||||||||||||||||
| 639 | KERI | GLEIF | https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/2022-06-28_lei-digital-strategy-current_version-focus-vlei_v0.17_work.pdf | LEI Digital Strategy | The Global LEI System (GLEIS) has a unique opportunity to solve the problem of trust for legal entities on a global scale. It can enable digital transformation in a way that is interoperable, independent and autonomous. As a regulatory endorsed system overseen by the Regulatory Oversight Committee (ROC), the GLEIS is the only system that establishes a recognized, monitored and standardized global identity for legal entities that, whenever possible, is linked to the national ID system in that jurisdiction. The system is underpinned by open data, meaning any person or company can access the LEI and its associated reference data. The GLEIS also bridges traditional and online processes by serving as a tool to identify the counterparty in any transaction and can aggregate data on legal entities held in repositories.<br><br>GLEIF’s digital strategy for the LEI centers on two methods for cryptographically binding the LEI to its organization – digital certificates and Verifiable Credentials. | From banking to production and supply chain management, industries worldwide are adjusting to the digitization of processes and transactions. | https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei | Post | Organization | 2022-06-08 | ||||||||||||||||||||||||||||||
| 640 | KERI | IDCommons | GLEIF | IIW | GLEIF vLEI with KERI | The Global Legal Entity Identifier Foundation (GLEIF) proposes that the Legal Enitity Identifier (LEI) can be used to establish a chain of trust for organizational identity.<br><br>In this session, GLEIF shares plans and progress regarding its development program to create an ecosystem and credential governance framework, together with a technical supporting infrastructure, for a verifiable LEI (vLEI), a digitally verifiable credential containing the LEI. | https://iiw.idcommons.net/20K/_GLEIF_vLEI_with_KERI | Session Notes | Organization | 2021-05-07 | ||||||||||||||||||||||||||||||
| 641 | KERI | TOIP | ACDC (Authentic Chained Data Container) Task Force | The purpose of the Authentic Chained Data Container (ACDC) Task Force is to help draft and incubate a family of IETF-focused specifications that defines the standard requirements for the semantics of Authentic Chained Data Containers. The semantics of ACDCs include both source provenance and authorization provenance or delegation. The hypothesis is that the W3C Verifiable Credential standard may be expanded to serve as an Authentic Data Container (ADC) with authentic provenance chains (APC) as a super semantic. This may be further expanded to support both a source provenance sub-semantic and a delegated authorization sub-semantic. These are all encapsulated into the semantics with supporting syntax of an ACDC. | https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force | page | Organization | 2021-01-19 | ||||||||||||||||||||||||||||||||
| 642 | KERI | Trusted Computing Group | Trusted Computing Group | The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define and promote open, vendor-neutral, global industry specifications and standards, supportive of a hardware-based root of trust, for interoperable trusted computing platforms.TCG’s core technologies include specifications and standards for the Trusted Platform Module (TPM), Trusted Network Communications (TNC) and network security and self-encrypting drives. TCG also has work groups to extend core concepts of trust into cloud security, virtualization and other platforms and computing services from the enterprise to the Internet of Things. | https://trustedcomputinggroup.org/ | https://trustedcomputinggroup.org/wp-content/plugins/revslider/public/assets/assets/dummy.png | site | Organization | ||||||||||||||||||||||||||||||||
| 643 | KERI | Micro Controller Tips | Maria Guerra | What is DICE architecture? | DICE stands for Device Identifier Composition Engine, and it is a security standard created by the Trusted Computing Group (TCG) which has been addressing security issues for years. TCG announced the establishment of DICE Architecture, or DICE Architecture Work Group to address the need for increased security in the Internet of Things (IoT) therefore targeting products such as MCUs and systems on a chip (SoCs). | https://www.microcontrollertips.com/what-is-dice-architecture-faq/ | https://www.microcontrollertips.com/wp-content/uploads/2018/06/DICE-featured.jpg | faq | Organization | 2018-07-27 | ||||||||||||||||||||||||||||||
| 644 | KERI | IDCommons | Samuel Smith | IIW | Security Considerations of KERI. Why and how KERI provides secure portability | Harm that can be done to the a controller: Unavailability, loss of control authority, externally forced duplicity<br><br>Harm that can be done to a validator: Inadvertent acceptance of verifiable - but forged or duplicitous events<br><br>Breaking the promise of global consistency by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before. | https://iiw.idcommons.net/2K/_Security_Considerations_of_KERI._Why_and_how_KERI_provides_secure_portability | Session Notes | Development | 2021-05-06 | ||||||||||||||||||||||||||||||
| 645 | KERI | DIF | Q&A about KERI’s Security model and Guarantees - Part II Security | *Q: What are the security risks of KERI with regard to the identity protocol?<br><br>Harm that can be done to the a controller: Unavailability, loss of control authority, externally forced duplicity<br><br>Harm that can be done to a validator: Inadvertent acceptance of verifiable - but forged or duplicitous events<br><br>Breaking the promise of global consistemcy by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before.<br><br>### Q: How secure is the KERI infrastructure?<br><br>KERI changes the discussion about security. From a discussion about the security of infrastructure to a discussion about the security of your key management infrastructure. Most people when they think security, the think “oh, blockchain!”: permissioned or permissionless, how hard is it to get 51% attack, etc.Non of that matters for KERI. KERI is all about “are your private keys private?!” And if yes, that drastically slims down the security discussion to brute force attacks to public keys. And because the next public keys are in fact protected by a hash, you have to brute force the hash algorithm, that is post-quantum secure. So that is a very high level of infrastructural security.<br><br>So private key management and protection is the root of your security in KERI.<br><br>### *Q: You are arguing KERI affords greater security than a decentralized linear event system like Bitcoin?<br><br>…you would be fundamentally arguing that you can record a singular, immutable linear event history more securely than Bitcoin, and I see nothing in KERI that would indicate that.<br><br>Read the answer to [this](https://identity.foundation/keri/docs/Q-and-A-Security.html#keri-is-basically-a-series-of-pay2publickeyhash-transactions) first.<br><br>If you read Szabo’s paper on threshold structures, you get security of the same type when ever you use a threshold structure, be it MFA, Multi-Sig, or Distributed consensus. They all are using a combination of multiple relatively weak attack surfaces that must be simulatenously compromised for a successful attack. So multiplying simulatneous weak surfaces = functional equivalent of a stronger attack surface. So when you look at KERI you see that the security is primarily due to cryptographic strength and the witnesses are not the primary source of security but merely secure one thing, that is the availability of the KEL for an identifier. Not the KEL itself. The KEL iteself is secured by signatures.<br><br>From a Validator perspective their security is due to duplicity detection. Successful attack against duplicity detection requires an eclipse attack. Ledgers such as bitcoin are also susceptible to eclipse attacks. So in an apples to apples (resistance to eclipse attack) a KERI watcher network of comparable reach (1000’s of watchers) would have comparable resistance to an eclipse attack.<br><br>### Q: Differences between blockchain-based security and KERI security<br><br>* Where KERI doesn’t need total ordering in its logs, blockchain do need that. What KERI needs is watchers that construct string of event in the relative order of reception of the KEL {TBW please explain or improve this: what is this, why is it important?}<br><br>* Another characteristic is that KERI identifiers are transferable and blockchain-based identifiers are not, they are bound to their ledger. | Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol | https://identity.foundation/keri/docs/Q-and-A-Security.html#qa-section-keri-security-considerations | https://identity.foundation/keri/images/Direct-mode-kel-kerl.png | page | Development | 2021-04-06 | ||||||||||||||||||||||||||||||
| 646 | KERI | Samuel Smith | W3C DID Security Concerns | **Certificate Transparency Solution**<br>- Public end-verifiable append-only event log with consistency and inclusion proofs <br>- End-verifiable duplicity detection = ambient verifiability of duplicity <br>- Event log is third party infrastructure but it is not trusted because logs are verifiable. <br>- Sparse Merkle trees for revocation of certificates<br>- (related EFF SSL Observatory) | https://github.com/SmithSamuelM/Papers/blob/master/presentations/W3C_DID_Security_Concerns.pdf | Development | 2020-01-14 | |||||||||||||||||||||||||||||||||
| 647 | KERI | DIF | https://hackmd.io/orhyiJkLT721v4PCPkvQiA?both | Implementation Notes for KERI | The interpretation of the data associated with the digest or hash tree root in the seal is independent of KERI. This allows KERI to be agnostic about anchored data semantics. Another way of saying this is that seals are data agnostic; they don’t care about the semantics of its associated data. This better preserves privacy because the seal itself does not leak any information about the purpose or specific content of the associated data. Furthermore, because digests are a type of content address, they are self-discoverable. This means there is no need to provide any sort of context or content specific tag or label for the digests. Applications that use KERI may provide discovery of a digest via a hash table (mapping) whose indexes (hash keys) are the digests and the values in the table are the location of the digest in a specific event. To restate, the semantics of the digested data are not needed for discovery of the digest within a key event sequence. | https://github.com/decentralized-identity/keri/blob/master/implementation.md | Development | 2020-05-16 | ||||||||||||||||||||||||||||||||
| 648 | KERI | IDCommons | Samuel Smith, Dave Huseby | IIW | KERI and ADS Key State Provenance Logs Kumbaya (KEL and ADPL) | This was a meeting of the minds between myself and Sam Smith and Adrian Gropper that was hugely successful. We all decided to use the term "endorser" for what we all called "registrar"/"witness"/"notary". We also realized that the KERI proposal for encoding is good enough for authentic data provenance logs and we will be using the KERI encoding. Sam has modified the spec for KERI key event logs to include scripting capabilities needed in the authentic data economy for doing things like cross-chain atomic swaps for selling non-fungible authentic data (NFADs).<br><br>The result is that there is grand convergence on the encoding and file format for key event provenance logs that will be supported by both KERI networks and the broader authentic data economy. | https://iiw.idcommons.net/24H/_KERI_and_ADS_Key_State_Provenance_Logs_Kumbaya_(KEL_and_ADPL) | Session Notes | Development | 2021-05-06 | ||||||||||||||||||||||||||||||
| 649 | KERI | Jolocom | Jolocom’s latest contributions to DIF | Jolocom added support for an [off-chain element based on KERI](https://github.com/decentralized-identity/keri/blob/master/kids/KERI_WP.pdf). This is in addition to the Jolocom DID method (did:jolo and did:keri), which supports the Jolocom-Lib, our own SDK and the Jolocom SmartWallet. | https://jolocom.io/blog/jolocoms-contributions-to-dif/ | Development | 2021-01-19 | |||||||||||||||||||||||||||||||||
| 650 | KERI | SSI-Meetup | https://www.youtube.com/watch?v=izNZ20XSXR0 | Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58 | https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/ | Presentations | 2020-05-19 | |||||||||||||||||||||||||||||||||
| 651 | KERI | Samuel Smith | KERI Overview | **Separation of Control** Shared (permissioned) ledger = shared control over shared data.<br>* Shared data = good, shared control = bad.<br>* Shared control between controller and validator may be problematic for governance, scalability, and performance.KERI = separated control over shared data.<br>* Separated control between controller and validator may provide better decentralization, more flexibility, better scalability, lower cost, higher performance, and more privacy at comparable security. | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI2_Overview.web.pdf | 2.54 | Presentations | 2020-10-22 | ||||||||||||||||||||||||||||||||
| 652 | KERI | Samuel Smith | The Duplicity Game: or why you can trust KERI | **Inconsistency vs. Duplicity**<br>- inconsistency: lacking agreement, as two or more things in relation to each other<br>- duplicity: acting in two different ways to different people concerning the same matter<br>**Internal vs. External Inconsistency** <br>- Internally inconsistent log = not verifiable.<br>- Log verification from self-certifying root-of-trust protects against internal inconsistency.<br>Externally inconsistent log with a purported copy of log but both verifiable = duplicitous.<br>Duplicity detection protects against external inconsistency. | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/DuplicityGame_IIW_2020_A.pdf | Presentations | 2020-05-09 | |||||||||||||||||||||||||||||||||
| 653 | KERI | Samuel Smith | Key Event Receipt Infrastructure (KERI) Model for a Universal DKMI | **KERI Nomenclature**<br>* **self-certifying identifier**: includes public key<br>* **digital signature**: unique non-repudiable (cypher suite known)<br>* **digest**: collision resistant hash of content<br>* **signed digest**: commitment to content<br>* **controller**: controlling entity of identifier<br>* **message**: serialized data structure event: actionable message<br>* **key event**: key management operation<br>* **inception event**: unique self-signed event that creates identifier and controlling key(s)<br>* **rotation event**: self-signed uniquely ordered event from a sequence that changes the set of controlling keys<br>* **verifier**: cryptographically verifies signature(s) on an event message.<br>* **witness**: entity that may receive, verify, and store key events for an identifier. Each witness controls its own identifier used to sign key event messages, controller is a special case of witness.<br>* **receipt**: event message or reference with one or more witness signatures<br>* **key event log**: ordered record of all self-signed key event messages key event<br>* **receipt log**: ordered record of all key event receipts for a given set of witnesses<br>* **validator**: determines current authoritative key set for identifier from at least one key event (receipt) log. <br>* **judge**: determines current authoritative key set for identifier from the key event receipt logs from a set of witnesses.<br>* **pre-rotation**: commitment to next rotated key set in previous rotation or inception event | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_Overview.pdf | Presentations | 2019-12 | |||||||||||||||||||||||||||||||||
| 654 | KERI | Samuel Smith | KERI for Muggles IIW #31 Day 1 - Session #220 October 2020 | KERI is a new approach to decentralized identifiers and decentralized key management that promises significant benefits for SSI (self-sovereign identity) and ToIP (Trust over IP) infrastructure | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_for_Muggles.pdf | Presentations | 2020-10-21 | |||||||||||||||||||||||||||||||||
| 655 | KERI | Samuel Smith | Verifiable Trust Bases | * KERI enables cryptographic proof-of-control-authority (provenance) for each identifier.<br>* A proof is in the form of an identifier’s key event receipt log (KERL).<br>* KERLs are *End Verifiable*:<br> * End user alone may verify. Zero trust in intervening infrastructure.<br>* KERLs may be *Ambient Verifiable*:<br> * Anyone may verify anylog, anywhere, at anytime.<br>* KERI = self-cert root-of-trust + certificate transparency + KA2CE + recoverable + post-quantum. | https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERIVerifiableTrustBases.web.pdf | 2.53 | Presentations | 2020-10-20 | ||||||||||||||||||||||||||||||||
| 656 | KERI | Springer | Girault, M. | EUROCRYPT 1991 | Self-certifiepublic keys | https://link.springer.com/content/pdf/11007%2F3-540-46416-6_42.pdf | Literature; Self-Certifying Identifiers | 1991 | ||||||||||||||||||||||||||||||||
| 657 | KERI | MIT | Kaminsky M., Banks E. | SFS-HTTP: Securing the Web with Self-Certifying URLs | https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps | Literature; Self-Certifying Identifiers | 1999 | |||||||||||||||||||||||||||||||||
| 658 | KERI | Sigops | Mazieres D., Kaashoek M. F. | MIT | Escaping the Evils of Centralized Control with self-certifying pathnames | http://www.sigops.org/ew-history/1998/papers/mazieres.ps | Literature; Self-Certifying Identifiers | 2000 | ||||||||||||||||||||||||||||||||
| 659 | KERI | CSAIL | Mazieres D. | Self-certifying File System | https://pdos.csail.mit.edu/~ericp/doc/sfs-thesis.ps | Literature; Self-Certifying Identifiers | 2000-06-01 | |||||||||||||||||||||||||||||||||
| 660 | KERI | Trusted Computing Group | Implicit Identity Based Device Attestation | https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf | Literature; Self-Certifying Identifiers | 2018-03-05 | ||||||||||||||||||||||||||||||||||
| 661 | KERI | Samuel Smith | Open Reputation Framework | https://github.com/SmithSamuelM/Paperblob/master/whitepapers/open-reputation-low-level-whitepaper.pdf | Literature; Autonomic Identifiers | 2015-05-13 | ||||||||||||||||||||||||||||||||||
| 662 | KERI | Samuel Smith, Khovratovich D. | Identity System Essentials | https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf | Literature; Autonomic Identifiers | 2016-03-29 | ||||||||||||||||||||||||||||||||||
| 663 | KERI | Samuel Smith | Decentralized Autonomic Data (DAD) and the three R’s of Key Management | Rebooting the Web of Trust RWOT 6, Spring 2018 | https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf | Literature; Autonomic Identifiers | 2018-05-23 | |||||||||||||||||||||||||||||||||
| 664 | KERI | arXiv | Samuel Smith | Key Event Receipt Infrastructure (KERI) Design and Build | https://arxiv.org/abs/1907.02143 | Literature; Autonomic Identifiers | 2019-07-03 | |||||||||||||||||||||||||||||||||
| 665 | KERI | Conway S, Hughes A | RWOT 7 | A DID for Everything | https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf | Literature; Autonomic Identifiers | 2018-09-26 | |||||||||||||||||||||||||||||||||
| 666 | KERI | WeboftrustInfo | Stocker C, Samuel Smith, Juan Caballero | RWOT10 | Quantum Secure DIDs | https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf | Literature; Autonomic Identifiers | 2020-07-09 | ||||||||||||||||||||||||||||||||
| 667 | KERI | ACMQueue | http://www.certificate-transparency.org/home | Ben Laurie | Certificate Transparency: Public, verifiable, append-only log | https://queue.acm.org/detail.cfm?id=2668154 | Literature; Certificate Transparency | 2014-09-08 | ||||||||||||||||||||||||||||||||
| 668 | KERI | Links | Ben Laurie, Emilia Kasper | Revocation Transparency | https://web.archive.org/web/20230309211444/https://www.links.org/files/RevocationTransparency.pdf | Literature; Certificate Transparency | 2015 | |||||||||||||||||||||||||||||||||
| 669 | KERI | Steve Tout | Non Conformist Innovation Summit Closing Keynote #2 - Sam Smith | The Economics of Its & Bits - Digital Identity - Freedom Privacy Control Security | https://www.youtube.com/watch?v=L82O9nqHjRE | Assorted | 2020-07-23 | |||||||||||||||||||||||||||||||||
| 670 | KERI | IDCommons | Robert Mitwicki | IIW | Supply chain – ACDC and KERI + DEMO | Authentic Chain Data Containers (ACDC) - is a technology which allows to secure and chain data in a generic way. It aims to improve the way we do VC and how we think about authentic data.<br><br>After explanation of ACDC, a demo was performed where it was shown how KERI can enable authentic data flow within the supply chain without the need of having any blockchain nor one single network. | https://iiw.idcommons.net/14K/_Supply_chain_%E2%80%93_ACDC_and_KERI_+_DEMO | Session Notes | Assorted | 2021-05-07 | ||||||||||||||||||||||||||||||
| 671 | KERI | personal | Robert Mitwicki | KERI: Facilitating secure data flows in an auditable supply chain | Supply Chain and why you need Blockchain <br>- Time-stamping, tracking, and automating transactions, so that events can be audited in real time <br>- Minimizing the involvement of intermediaries such as bankers, insurers, and brokers <br>- Setting up a wide range of self-executing contracts to automate repetitive processes such as billing and shipping <br>- Establishing proof of quality, provenance, payment, and performance to minimize counterfeiting and fraud <br>- Making it easier, faster, and cheaper to onboard new vendors and partners by assigning digital IDs<br>Supply Chain and why you DON’T want Blockchain <br>- Lack of Interoperability - my ledger vs someone else ledger, how to bridge it and navigate<br>- Problem with Governance Framework - who decided who can join? <br>- Scaling<br>- Privacy | https://docs.google.com/presentation/d/1tF_OFGAKUz9RKCLTdwDYDu7hJuEbFz-LQ6PAih7HBK8/edit#slide=id.p | Presentation | Assorted | 2020-10-10 | |||||||||||||||||||||||||||||||
| 672 | Cryptography | SRI | https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0109.html | David Balenson, Nick Genise | Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and Cryptography Implementation Recommendations | Cryptography used by U.S. government entities in operational systems must conform to relevant federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography. As part of its in-depth technical due-diligence to enable operational capabilities for DHS/CBP, DHS/PRIV and DHS/USCIS, the U.S. Department of Homeland Security’s Silicon Valley Innovation Program (SVIP) sponsored independent nonprofit research center SRI International to conduct a cryptographic review of the W3C Verifiable Credentials Data Model and W3C Decentralized Identifiers standards. The review provided constructive feedback and recommendations for technology developers and W3C standards developers to increase their level of compliance with federal government standards. | http://www.csl.sri.com/papers/vcdm-did-crypto-recs/ | Paper | Assorted | Verifiable Credentials | 2023-01-01 | |||||||||||||||||||||||||||||
| 673 | Cryptography | Zero Knowledge | ZeroKnowledge | ZK for Authentication With Nolan and Locke from NuID | Here are a few of the articles mentioned in the episode:<br>–[Universally Composable Direct Anonymous Attestation](https://eprint.iacr.org/2015/1246.pdf) by Jan Camenisch , Manu Drijvers , and Anja Lehmann<br>–[Practical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain](https://eprint.iacr.org/2015/1246.pdf) by Jan Camenisch , Manu Drijvers , and Anja Lehmann<br>–[Privacy-Preserving User-Auditable Pseudonym Systems](https://researcher.watson.ibm.com/researcher/files/zurich-ANJ/main_nymlog.pdf) by Jan Camenisch & Anja Lehmann IBM Research – Zurich | Zero Knowledge Podcast is a show about zk proofs and other blockchain tech. Learn about the latest in zero knowledge research, cryptography-enabled privacy tech. | https://www.zeroknowledge.fm/154 | https://i0.wp.com/zeroknowledge.fm/wp-content/uploads/2021/06/Discourse_icon.svg.png?fit=800%2C815&ssl=1 | episode | Assorted | 2020-11-04 | |||||||||||||||||||||||||||||
| 674 | Cryptography | Soatok | https://lists.w3.org/Archives/Public/public-credentials/2022May/0048.html | Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022 | Most people just defer to SafeCurves, but it’s a little dated: We have complete addition formulas for Weierstrass curves now, but SafeCurves doesn’t reflect that.<br><br>For the purpose of simplicity, I’m not going to focus on a general treatment of Elliptic Curve Cryptography (ECC), which includes pairing-based cryptography, Elliptic-Curve Diffie-Hellman, and (arguably) isogeny cryptography.<br><br>Instead, I’m going to focus entirely on elliptic curve digital signature algorithms. | A cartoon wild canid on the Internet provides general guidance on elliptic curve cryptography parameter choices. | https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/ | Post | Assorted | 2022-05-19 | ||||||||||||||||||||||||||||||
| 675 | Cryptography | CCG | https://w3c.github.io/cg-reports/credentials/CG-FINAL-data-integrity-20220722/ | JSON Web Signature 2020 | 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. | https://www.w3.org/community/reports/credentials/CG-FINAL-lds-jws2020-20220721/ | Specification | Specification | Verifiable Credentials | 2022-07-21 | ||||||||||||||||||||||||||||||
| 676 | Cryptography | CCG | https://w3c.github.io/cg-reports/credentials/CG-FINAL-lds-jws2020-20220721/ | ECDSA Cryptosuite v2019 | This specification describes a Data Integrity Cryptosuite for use when generating a digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA) based on the Standards for Efficient Cryptography over prime fields using a verifiably random Elliptic Curve (secpr1). The approach is accepted by the U.S. National Institute of Standards and meets U.S. Federal Information Processing requirements when using cryptography to secure digital information. https://www.w3.org/community/reports/credentials/CG-FINAL-di-ecdsa-2019-20220724/ | https://www.w3.org/community/reports/credentials/CG-FINAL-di-ecdsa-2019-20220724/ | Specification | Specification | Verifiable Credentials | 2022-07-24 | ||||||||||||||||||||||||||||||
| 677 | Cryptography | CCG | https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-ecdsa-2019-20220724/ | EdDSA Cryptosuite v2020 | This specification describes a Data Integrity Cryptosuite for use when creating or verifying a digital signature using the twisted Edwards Curve Digital Signature Algorithm (EdDSA) and Curve25519 (ed25519). The approach is accepted by the U.S. National Institute of Standards in the latest FIPS 186-5 draft and, after ratification, is expected to meet U.S. Federal Information Processing requirements when using cryptography to secure digital information. | https://www.w3.org/community/reports/credentials/CG-FINAL-di-eddsa-2020-20220724/ | Specification | Specification | Verifiable Credentials | 2022-07-24 | ||||||||||||||||||||||||||||||
| 678 | Cryptography | CCG | https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-eddsa-2020-20220724/ | Data Integrity 1.0 | This specification describes mechanisms for ensuring the authenticity and integrity of structured digital documents using cryptography, such as digital signatures and other digital mathematical proofs. | https://www.w3.org/community/reports/credentials/CG-FINAL-data-integrity-20220722/ | Specification | Specification | Verifiable Credentials | 2022-07-22 | ||||||||||||||||||||||||||||||
| 679 | Cryptography | IETF | https://self-issued.info/?p=2260 | Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE | This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). | Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE | https://datatracker.ietf.org/doc/draft-ietf-cose-bls-key-representations/ | Specification | Specification | 2023-03-13 | ||||||||||||||||||||||||||||||
| 680 | Cryptography | NIST | PQC Standardization Process: Announcing Four Candidates to be Standardized, Plus Fourth Round Candidates | NIST has completed the third round of the Post-Quantum Cryptography (PQC) standardization process, which selects public-key cryptographic algorithms to protect information through the advent of quantum computers. A total of four candidate algorithms have been selected for standardization, and four additional algorithms will continue into the fourth round. | NIST is announcing four Post-Quantum Cryptography candidates for standardization, plus candidates for a fourth round of analysis. | https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4 | Post | Specification | 2022-07-05 | |||||||||||||||||||||||||||||||
| 681 | Cryptography | CISA | Prepare for a New Cryptographic Standard to Protect Against Future Quantum-Based Threats | The National Institute of Standards and Technology (NIST) has announced that a new post-quantum cryptographic standard will replace current public-key cryptography, which is vulnerable to quantum-based attacks. Note: the term “post-quantum cryptography” is often referred to as “quantum-resistant cryptography” and includes, “cryptographic algorithms or methods that are assessed not to be specifically vulnerable to attack by either a CRQC [cryptanalytically relevant quantum computer] or classical computer.” (See the National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems for more information). | https://www.cisa.gov/uscert/ncas/current-activity/2022/07/05/prepare-new-cryptographic-standard-protect-against-future-quantum | https://www.cisa.gov/profiles/cisad8_gov/themes/custom/gesso/dist/images/icon-dot-gov.svg | Post | Quantum | 2022-07-05 | |||||||||||||||||||||||||||||||
| 682 | Cryptography | CCG Mailing List | Manu Sporny | Future-proofing VCs via multiple signatures | What this means is that it is now possible to not have to depend on one signature format, and instead use multiple to meet different needs. The VC above supports NIST-approved cryptography today, while enabling the advanced use of BBS+ (if an organization would like to use it /before/ it is standardized at IETF), and also enabling protection if a quantum computer were to break both Ed25519 and BBS+... all on the same VC in a fairly compact format. | https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0043.html | Discussion | Quantum | Verifiable Credentials | 2022-01-06 | ||||||||||||||||||||||||||||||
| 683 | Cryptography | CCG Mailing List | Orie Steele | New Work Item Incubating for IETF: JSON Encoding for Post Quantum Signatures from Mike Prorock on 2022-02-01 (public-credentials@w3.org from February 2022) | I look forward to continuing to work on JSON encoding for post quantum signature schemes.<br><br>In particular, support for JWS and JWK as building blocks for higher order cryptographic systems, such as DIDs and VCs.<br><br>If you are interested in contributing, please feel free to open issues here:[https://github.com/mesur-io/post-quantum-signatures](https://github.com/mesur-io/post-quantum-signatures) | https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0008.html | Discussion | Quantum | 2022-02-01 | |||||||||||||||||||||||||||||||
| 684 | Cryptography | CCG Mailing List | Mike Prorock | Post Quantum and Related | Please do be tracking the upcoming changes around crypto primitives,<br>especially signature methods. See the recent NIST announcement for more<br>details, but effectively, be planning on future support for CRYSTALS-KYBER,<br>and on the signature side of things CRYSTALS-Dilithium, FALCON, and SPHINCS+<br><br>NIST Announcement here:<br>https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4<br><br>And a pretty good game plan from CISA with some timing implications here:<br>https://www.cisa.gov/uscert/ncas/current-activity/2022/07/05/prepare-new-cryptographic-standard-protect-against-future-quantum<br><br>The TLDR is to assume that we need hard answers as a community, and at the<br>standards level, on crypto agility by 2024, as well as support for the key<br>algorithms as listed above.<br><br>I would also think that any new specs being drafted should reference these<br>coming changes and start to work them in. I would also be proactive on<br>adding in references as appropriate to specs you might be an editor or<br>author for (or just a contributor). | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0010.html | Discussion | Quantum | jose/cose | 2022-07-06 | ||||||||||||||||||||||||||||||
| 685 | Cryptography | CCG Mailing List | Joosten, H.J.M. | [CEIP] Draft paper on Cryptographically Enforceable Issuer Policies | my colleague Sterre and I drafted [a paper that we provisionally called Cryptographically Enforceable Issuer Policies](https://docs.google.com/document/d/1c8kIUqB2BBzM3usfD0_s5wu_z6K2KndzJ4uK_oZcPOs/edit?usp=sharing), which describes our current thinking on this topic.<br><br>The paper isn’t finished. We need more text in the ‘discussions’ section, and hope that by making the draft available we’ll get the discussions that we (or you?) can describe in there. Also, we might have missed stuff that you as a reader need for a proper understanding of what this is all about, and to start pondering for what (other) purposes all this might be used. Or why this proposal is a very bad idea that we should not spend any more time on. | https://lists.w3.org/Archives/Public/public-credentials/2021May/0170.html | Discussion | Quantum | 2021-05-31 | |||||||||||||||||||||||||||||||
| 686 | Cryptography | CCG Mailing List | Rieks Joosten | Blog on SSI and Cryptographically Enforceable Policies | I've posted a new SSI blog entitled: "[Protecting Sensitive Parts of Credentials with Cryptographically Enforceable Policies](https://blockchain.tno.nl/blog/protecting-sensitive-parts-of-credentials-with-cryptographically-enforceable-policies/)".<br><br>It has a proposal that enables credential issuers to encrypt sensitive parts of credentials in such a way that can only be decrypted by parties tha satisfy the issuer's policy (that was used to encrypt these parts). The blog motivates the need, introduces a high-level architecture, explains how it would work, and discusses some issues that need to be looked into. | https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0032.html | Discussion | Discussion | 2022-02-08 | |||||||||||||||||||||||||||||||
| 687 | Cryptography | CCG Mailing List | Marcus Sabadello | Universal signature verifier | We (Danube Tech) have a "Universal Verifier" here: [https://univerifier.io/](https://univerifier.io/)<br><br>But I don't claim that it actually supports all the credential formats and signature suites in existence...<br><br>Especially considering that at the last Internet Identity Workshop a lot of different formats were identified | https://lists.w3.org/Archives/Public/public-credentials/2022May/0005.html | Discussion | Discussion | 2022-05-04 | |||||||||||||||||||||||||||||||
| 688 | Cryptography | CCG Mailing List | https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/ | Manu Sporny | Updating SafeCurves for 2022... | I found this blog post useful for the upcoming VC2WG cryptosuite work:<br><br>Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022<br><br>https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/<br><br>It suggests updates to the SafeCurves website:<br><br>https://safecurves.cr.yp.to/<br><br>... and does a fairly good job of boiling down the choices and<br>misinterpretations in the space.<br><br>Bonus points because it also included a link to this undiscovered gem:<br><br>https://www.howmanydayssinceajwtalgnonevuln.com/<br><br>Worth a read for those of us that are thinking about good cryptosuite choices<br>for VCs in 2022. | https://lists.w3.org/Archives/Public/public-credentials/2022May/0048.html | Discussion | Discussion | 2022-05-24 | ||||||||||||||||||||||||||||||
| 689 | Cryptography | CCG Mailing List | Manu Sporny | Cross-vendor interop for Data Integrity and Ed25519Signature2020 achieved | We are happy to announce today that we have our first demonstration of cross-vendor interoperability between Danube Tech and Digital Bazaar for verification regarding the Data Integrity and Ed25519Signature2020 work items | https://lists.w3.org/Archives/Public/public-credentials/2022May/0034.html | Discussion | Discussion | 2022-05-17 | |||||||||||||||||||||||||||||||
| 690 | Cryptography | CCG Mailing List | Manu Sporny | Streamlining Data Integrity Cryptosuites | How many crypto suites could there be? Well, there are at least this many today:<br>● https://w3id.org/security/suites/ed25519-2020/v1<br>● https://w3id.org/security/suites/x25519-2019/v1<br>● https://w3id.org/security/suites/merkle-disclosure-2021/v1<br>● https://w3id.org/security/suites/secp256k1recovery-2020/v1<br>● https://w3id.org/security/suites/pgp-2021/v1<br>● https://w3id.org/security/suites/blockchain-2021/v1<br>● https://w3id.org/security/suites/jws-2020/v1<br>● https://w3id.org/security/suites/bls12381-2020/v1<br>● https://w3id.org/security/suites/eip712sig-2021/v1<br>● https://w3id.org/security/suites/secp256k1-2020/v1<br>● https://w3id.org/security/suites/secp256k1-2019/v1<br>● https://w3id.org/security/suites/merkle-2019/v1<br>● https://w3id.org/security/suites/chained-2021/v1 | https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0115.html | Discussion | Discussion | 2022-07-31 |