Remove references to "cryptocurrency" in favor of "Bitcoin" or "digital money"

$> grep --exclude-dir node_modules -r "crypto"
./learn/discussions/blockchain-crypto-tbd.mdx:  thumbnail: /img/learn/blockchain_crypto_tbd.png
./learn/discussions/blockchain-crypto-tbd.mdx:  <Audio url="https://soundcloud.com/user-625850228/blockchain-crypto-and-tbd-oh" />
./.docusaurus/registry.js:  'content---learn-discussions-blockchain-crypto-tbd-8-eb-449': [() => import(/* webpackChunkName: 'content---learn-discussions-blockchain-crypto-tbd-8-eb-449' */ '@site/learn/discussions/blockchain-crypto-tbd.mdx'), '@site/learn/discussions/blockchain-crypto-tbd.mdx', require.resolveWeak('@site/learn/discussions/blockchain-crypto-tbd.mdx')],
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:              "unversionedId": "discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:              "id": "discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:              "source": "@site/learn/discussions/blockchain-crypto-tbd.mdx",
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:              "slug": "/discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:              "permalink": "/learn/discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:                  "thumbnail": "/img/learn/blockchain_crypto_tbd.png"
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:                "permalink": "/learn/discussions/blockchain-crypto-tbd"
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:                    "id": "discussions/blockchain-crypto-tbd"
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:          "content": "<head>\n  <meta property=\"og:title\" content=\"Web Assembly with ChatGPT\" />\n  <meta property=\"og:url\" content='https://developer.tbd.website/blog/chatgpt-writingcode' />\n   <meta name=\"twitter:card\" content=\"summary\" />\n  <meta name=\"twitter:site\" content=\"@tbddev\" />\n  <meta name=\"twitter:title\" content=\"Web Assembly with ChatGPT\" />\n  <meta name=\"twitter:description\" content=\"Using ChatGPT to help add WASM support to the self-soverign identity SDK\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n\n## Web Assembly\n\n[Web Assembly](https://webassembly.org/) is a popular format for running binary applications in web browsers (with wide support).\n\nThis can have a few advantages but the interesting thing for us is that this can allow sharing of implementations of functionality: eg credential issuance, DID resolving, cryptographic funcitons etc which you may not want to necessarily re-implement in javascript or typescript.\n\nThe [SSI-SDK](https://github.com/TBD54566975/ssi-sdk) is an implementation of a lot of standards for self soverign identity, so it is a great candidate to expose via WASM to web apps. \n\nNow there is a whole lot of (lets face it: tedioius) machinery to get wasm to be compiled from go (ok if you are really curious you can [read the code](https://github.com/TBD54566975/ssi-sdk/pull/265/)), but the upshot of it is that there is a .wasm file produced which when consumed in just the right way in a web page, allows you to call functions from javascript, that look and feel like javascript, but are actually running in the web-assembly machiner (and compiled down from golang).\n\nSay you had a function in golang land which looked like this: \n\n```golang \n// Resolve attempts to resolve a DID for a given method\nfunc (dr Resolver) Resolve(did string, opts ...ResolutionOptions) (*DIDResolutionResult, error) {\n  ...\n```\n\nYou could call it from the web via:\n```javascript\nconsole.log(resolveDid(\"did:peer:0z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"));\n```\n\nand it would Just Work thanks to WASM! \nWell, thanks to WASM and a lot of boring glue. \n\n\n## ChatGPT\n\nBut the boring glue is what I am hear to talk about it, as it turns out ChatGPT can be quite helpful for the boring (but important) glue. \n\n(If you have been under a rock and haven't heard of ChatGPT - google it now and then come back)\n\nSo firstly, there is some work to be done to build a shim between the JS type world and the Golang type world: \n\n```golang\n// 1. Simplest function - note we wrap things with js.ValueOf (if a primitive you don't technically need to)\nfunc sayHello(_ js.Value, args []js.Value) interface{} {\n\treturn js.ValueOf(\"Hello from golang via wasm!\")\n}\n```\n\nThis gets more complicated when you have more complicated types, but essentially this is the pattern you follow to expose functionality. \nNow I am a pretty ordinary golang developer, so being lazy I thought I would see if I could teach ChatGPT about WASM and if it could write this glue code for me. \n\nHelpfully the ssi-sdk has a good amount of test coverage, so to teach ChatCPT about the api I was trying to expose, I pasted in a test case which exercised the api. \nThe functionality was the \"Resolve\" function above, and the test code showed how to use it. \n\nI then asked ChatGPT to provide a WASM friendly wrapper for that functionality:\n\n\n![chatgpt generated resolver](/img/chatgpt_resolver.png)\n\nTo do this, I gave it an example of some previously written code that uses some (unrelated) functionality and also exposes it to WASM. \nAs yoyu can see it was happy to provide an implementation which whilst close, with some minor tweaking. \n\nI was able to tidy it up and include it in the [pull request](https://github.com/TBD54566975/ssi-sdk/pull/265). Handy - thanks ChatGPT!\nMoreover, as I am an ordinary golang developer I was able to ask it to put in a retry on error (also some important glue) when using WASM from a web app (this staved a minor amount of googling): \n\n\n![chatgpt generated error handler](/img/chatgpt_error.png)\n\n\n## Parting thoughts\n\nWASM seems surpremely useful, and ChatGPT, while terrifying on one level, looks like it can really take away some of the grind work from developers, allowing us to move much faster into more platforms. And no, this post was NOT written by ChatGPT, but by a human."
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:          "content": "<head>\n  <title>TBD Partners with Circle!</title>\n  <meta name=\"description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/tbd-circle-partnership\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"TBD Partners with Circle!\" />\n  <meta property=\"og:description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n  <meta property=\"og:image\" content=\"/img/tbd_circle_partnership.png\" />\n\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/tbd-circle-partnership\" />\n  <meta name=\"twitter:title\" content=\"TBD Partners with Circle!\" />\n  <meta name=\"twitter:description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n  <meta name=\"twitter:image\" content=\"/img/tbd_circle_partnership.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![TBD Partners with Circle!](/img/tbd_circle_partnership.png)\n\nTBD and [Circle](https://www.circle.com/en/?_gl=1*14yjcwp*_up*MQ..&gclid=CjwKCAjwm8WZBhBUEiwA178UnPZbgZJJxhwK7ivE5Yx9FGW8PQ31-hc1O-njcLOmzcN2nzLz110FihoCgV4QAvD_BwE) are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications. The first step of which will support cross-border remittances and self-custody wallets that can hold stablecoins.\n\n<!--truncate-->\n\n\nWe are supporting USDC with an eye on a number of use cases that make it easy for developers to build on top of Block’s [tbDEX protocol](https://developer.tbd.website/projects/tbdex) and its [Web5](https://developer.tbd.website/blog/what-is-web5) decentralized identity platform.  \n\nThese use cases include:\n\n\n\n* Ubiquitous global on-and-off-ramps that connect traditional payments rails to digital assets, making it easier and more accessible for consumers and businesses around the world to benefit from the crypto economy.\n\n* Faster, lower cost remittances globally – starting from the U.S. to Mexico.\n\n* Self-custody wallets that can hold stablecoins – U.S. dollar denominated stablecoins – to provide a store of value to individuals in countries who must balance limited access to U.S. dollars with hyperinflationary environments.\n\nAn open approach solves for decentralized identity and enables safe, scaleable, and frictionless payments to work for consumers and merchants using stablecoins. \n\nThis partnership aims to make a significant impact on peoples’ everyday financial lives. It both fuels the potential for crypto to emerge as a mainstream payments system while establishing decentralized identity as the model for building trust in a scalable and privacy-preserving way.\n\nStay updated on our efforts here and connect with us [@tbd54566975](https://twitter.com/TBD54566975)."
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:          "content": "<head>\n  <title>Self Sovereign Identity, TBD, and Web5</title>\n  <meta name=\"description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/ssi-tbd-web5\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"Self Sovereign Identity, TBD, and Web5\" />\n  <meta property=\"og:description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n  <meta property=\"og:image\" content=\"https://developer.tbd.website/assets/images/ssi_tbd_web5-362c244c231552618f4e9abd2d4482c7.png\" />\n\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/ssi-tbd-web5\" />\n  <meta name=\"twitter:title\" content=\"Self Sovereign Identity, TBD, and Web5\" />\n  <meta name=\"twitter:description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n  <meta name=\"twitter:image\" content=\"https://developer.tbd.website/assets/images/ssi_tbd_web5-362c244c231552618f4e9abd2d4482c7.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![Self Sovereign Identity, TBD, and Web5](/img/ssi_tbd_web5.png)\n\nSelf Sovereign Identity (SSI) is an umbrella term well-detailed by Christopher Allen, and inspired by many in the Identity community before him, in his 2016 blog post: [*The Path to Self-Sovereign Identity*](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html), which identifies *Ten Principles of Self-Sovereign Identity:*\n\n<!--truncate-->\n\n1. **Existence.** *Users must have an independent existence.*\n2. **Control.** *Users must control their identities.*\n3. **Access.** *Users must have access to their own data.*\n4. **Transparency**. *Systems and algorithms must be transparent.*\n5. **Persistence.** *Identities must be long-lived.*\n6. **Portability.** *Information and services about identity must be transportable.*\n7. **Interoperability.** *Identities should be as widely usable as possible.*\n8. **Consent.** *Users must agree to the use of their identity.*\n9. **Minimalization.** *Disclosure of claims must be minimized.*\n10. **Protection.** *The rights of users must be protected.*\n\n\n\nSince 2016, a lot has happened! There have been a flurry of conventions, discussions, papers, standards, software, and industry wide adoption of technology based on the principles of SSI. The space is at its most mature, and only growing.\n\n[Block](https://squareup.com/us/en/press/square-changes-name-to-block)’s mission is economic empowerment. Historically, this has looked like building products and offering services such as [Square](https://squareup.com/), enabling millions of merchants _to take payments, manage staff, and conduct business in-store and online_, and [CashApp](https://cash.app/), which enables millions, especially the un and under-banked to send, spend, bank, and invest their money (and Bitcoin!). When [TBD](https://www.tbd.website/), a new business unit at [Block](https://block.xyz/) formed in 2021, we expanded on Block’s mission, setting out to help create _a decentralized future that returns ownership and control over your finances, data, and identity_. TBD’s mission is strongly aligned with the principles of SSI.\n\nTo facilitate our mission, TBD launched [Web5](https://developer.tbd.website/blog/what-is-web5): a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols. Web5 takes SSI concepts, standards, and software and provides them as an opinionated bundle to enable all that self sovereignty and digital identity has to offer. What TBD is building for Web5 has a number of components today, and more tomorrow. Among those are the Self Sovereign Identity SDK and Self Sovereign Identity Service (SSI SDK, and SSI Service), Decentralized Web Nodes (DWN), and Identity Wallets. At the time of writing, all of these components are under active development. This was an intentional move by the team to adopt an ‘open-by-default’ model, and include the community in the development of Web5 from the beginning.\n\nHere we’ll lay out the vision for a key component of Web5: Self Sovereign Identity. Specifically, how we at TBD are building standards based software in a community towards the goals of SSI and Web5. The two “SSI” named projects — the SSI Service and SSI SDK — sit along side Decentralized Web Nodes, Identity Wallets, User Interfaces, and much more — but focus on a set of standards-based building blocks of the Web5 stack.\n\n## Software Mission\n\n**TBD is developing open source, standards-based software to facilitate Self Sovereign Identity on Web5.**\n\n### Open Standards\n\nThe vision of SSI is realized via [Open Standards](https://en.wikipedia.org/wiki/Open_standard#:~:text=%22Open%20Standards%22%20are%20standards%20made,are%20intended%20for%20widespread%20adoption.). Crucially, these standards are accessible to all: to view and to contribute. You may not be aware of it, but you interact with Open Standards every day: whether via web browsers, hardware you use and their underlying protocols, programming languages, audio files, internet and bluetooth devices, text documents, chat applications, encryption you use and so much more. Open Standards facilitate nearly every aspect of modern computation.\n\nIn the SSI space there a number of standards bodies that facilitate SSI-standard development. Though we may utilize specifications in multiple organizations such as the [IETF](https://www.ietf.org/), [OpenID Foundation](https://openid.net/foundation/), the [World Wide Web Consortium (W3C)](https://www.w3.org/), and [Decentralized Identity Foundation (DIF)](https://identity.foundation/). TBD’s focus thus far has been primarily with the W3C and [DIF](http://identity.foundation/) organizations:\n\n### The W3C\n\nThe W3C, founded by [Tim Berners-Lee](https://en.wikipedia.org/wiki/Tim_Berners-Lee) in 1994, is one of the most prominent international standards organizations for the web. The W3C has a number of group types. Community Groups are the most open. The [Credentials Community Group](https://www.w3.org/community/credentials/) focused on Verifiable Credentials, and often serves as a staging ground for the [Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc), responsible for the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model) (i.e. the Verifiable Credentials specification). The [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did) is responsible for [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (i.e. the DID specification).\n\nTBD is a member of the W3C, actively utilizes the work items from all three groups, and has made contributions to each group’s corpus.\n\n### The Decentralized Identity Foundation\n\nThe Decentralized Identity Foundation, or DIF, was founded in 2017 to focus on Decentralized Identity. Since then, it’s expanded to house a number of working groups around Identifiers, Claims & Credentials, Sidetree, Secure Data Storage, Wallet Security, Interoperability, and more. DIF produces technical specifications, reference implementations (as in the case of Sidetree and [ION](https://identity.foundation/ion)), and coordinates standards and software implementations for players across the industry.\n\nTBD is a member of DIF, regularly attends working groups, contributing to both interoperability projects, specifications, and technical implementations.\n\n### Standards in Use\n\nThe set of standards we rely on and use for Web5 is unbound. However, we have a good sense of the standards we begin with. The list below will likely soon be out of date. Consider it as a reference as you orient yourself with what we’re working with.\n\n| Specification | Standards Body | Description | Status |\n| --- | --- | --- | --- |\n| [DID Core](https://www.w3.org/TR/did-core/) | [W3C Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did) | Decentralized Identifiers v1.0. | Recommendation |\n| [DID ION](https://identity.foundation/ion/) | [DIF Sidetree](https://identity.foundation/working-groups/sidetree.html) | A layer 2 Decentralized Identifier network that runs atop the Bitcion blockchain, built on the Sidetree protocol. | Ratified Specification |\n| [DID Key](https://w3c-ccg.github.io/did-method-key/) | [W3C CCG](https://www.w3.org/community/credentials/) | A simple method to create a DID using a single cryptographic key. | Unofficial Draft |\n| [DID Web](https://w3c-ccg.github.io/did-method-web/) | [W3C CCG](https://www.w3.org/community/credentials/) | A DID method that allows bootstrapping trust using a web domain. | W3C Internal Document |\n| [DID Peer](https://identity.foundation/peer-did-method-spec/) | [DIF Identifiers & Discovery](https://identity.foundation/working-groups/identifiers-discovery.html) | A DID method that can be used independent of any central source of truth, intended to be “cheap, fast, scalable, and secure.” | Draft |\n| [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | The Verifiable Credentials Data Model v1.1. | Recommendation |\n| [Data Integrity](https://github.com/w3c/vc-data-integrity) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | Describes mechanisms for ensuring the authenticity and integrity of structured digital documents…such as digital signatures. | Editor’s Draft |\n| [JSON Web Signature 2020](https://w3c.github.io/vc-jws-2020/) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | A cryptographic suite for the purpose of creating and verifying proofs for JSON Web Signatures using Linked Data Proofs. | Editor’s Draft |\n| [Verifiable Credentials JSON Schema](https://w3c-ccg.github.io/vc-json-schemas/v2/index.html) | [W3C CCG](https://www.w3.org/community/credentials/) | A mechanism to use JSON schemas to back a Verifiable Credential.  | Draft |\n| [Status List 2021](https://w3c-ccg.github.io/vc-status-list-2021/) | [W3C CCG](https://www.w3.org/community/credentials/) | A privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials. | Draft Community Group Report |\n| [VC Proof Format Test Suite](https://identity.foundation/JWS-Test-Suite/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A test suite providing interoperability testing and reporting for Verifiable Credentials and Presentation for Linked Data and JWT signature types. | Unofficial Draft |\n| [Presentation Exchange](https://identity.foundation/presentation-exchange/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A claim format and transport envelope agnostic format for Verifiers to articulate proof requirements, and for Holders to describe proofs according to those requirements. | Working Group Draft |\n| [Credential Manifest](https://identity.foundation/credential-manifest/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A common data format for describing the inputs a Subject must provide to an Issuer for evaluation and issuance of credentials, a means for a Subject to submit an application against those requirements, and a means for an Issuer to fulfill such an application. | Pre-Draft |\n| [Trust Establishment](https://identity.foundation/trust-establishment/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A means of communicating trust statements and relations between parties in decentralized identity environments. | Pre-Draft |\n| [Decentralized Web Node](https://identity.foundation/decentralized-web-node/spec/) | [DIF Secure Data Storage](https://identity.foundation/working-groups/secure-data-storage.html) | A DWN is a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given DID. DWNs provide multi-node sync, enabling the owning entity to secure, manage, and transact their data with others without centralizing factors. | Draft |\n\nFor brevity, I only included fifteen of the most prominent specifications comprising the foundations of the SSI stack in Web5. There are at least another half dozen either included or planned to be included in our software.\n\n## TBD Community\n\nTBD is interested in building a space for community-driven projects, community members gaining merge and moderation access to community resources, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5. \n\nWe are not interested in becoming a standards body itself. Instead, we are focused on fostering a self-sustaining community focused on building and building on Web5. To facilitate this, we can expand our existing tools like adding sections of our [Forums](https://forums.tbd.website/), creating new [Discord](https://discord.gg/tbd) channels, creating new purpose-specific [GitHub repositories](https://github.com/TBD54566975) and investing in new tools for collaboration like an ideas board, job listing page, or a Web5 wiki. I’d love to see a Web5 incubator similar to [Y Combinator](https://www.ycombinator.com/) that facilitates those building on Web5. The future’s possibilities are endless, and we are eager to adapt to the evolving needs of the community.\n\nSometimes, we may need more rigorous structure. As such, we are interested in forming working groups in the Web5 community where it makes sense. The output of these groups could be industry coordination, use-case building, software development, or even standards-related work that can be contributed to existing standards bodies. TBD has kicked off one such group to date around Credentials, first focused on creating a path for Know Your Customer (KYC) Credentials. This group already follows such a pattern: having built out [use-case documentation in GitHub](https://github.com/TBD54566975/credentials-working-group), having a purpose-specific [Discord channel](https://discord.com/channels/937858703112155166/969682739005624412), and [forum category](https://forums.tbd.website/c/self-sovereign-identity-users/credentials-working-group/6). Soon we’ll adapt this group to a more “office hours”-style format, allowing anyone in the community to show off their work, ask for assistance, and help shape our project development roadmaps. \n\nToday we have one [GitHub org](https://github.com/TBD54566975), run by the TBD team. We will open up roles for community management. Creating light processes for community-driven moderation and maintenance (e.g. managing pull requests, issues, labels, and milestones), in addition to having projects and repositories started and managed entirely by members of the community. One such idea we are considering is for a new GitHub organization for the “Web5 Community” to foster and highlight community-driven efforts. We’re additionally looking to launch an Incubation program that gives a formal path towards recognizing and promoting the work that begins in a grassroots manner in our community. We plan on making the rest of our tooling community-driven as well: today this means Discord and the Forums, tomorrow it will be a lot more!\n\nWhile this is something we are focused on internally, it is crucial that you as community members are able to make suggestions, plans, and directly influence change. Reach out on Discord, our Forums, gain mindshare for your ideas, and we will help make them a reality.\n\n## Open Source\n\nThe foundations of Web5 are [open source](https://github.com/TBD54566975). This means that its source code is publicly available and, as stewards, we rely on external contribution—Web5 is only successful with the full innovation of a global community. Certainly there are cases where code cannot be open source for various reasons: this applies to the TBD business as well as members of our community. We do not mandate open source, but it is a guiding principle. We believe in the power of open, and all that comes with it. The more open Web5 can be, the better it will be.\n\nProjects in the TBD GitHub may originate at TBD, or through the community (on our Discord, Forums). Today, the TBD team is acting as the primary steward and maintainer of all projects. As the community matures, we expect it to take the lead and for TBD to assume a higher-level maintainer role. We imagine this ends up looking like more community-driven projects, community members gaining merge and moderation access, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5. More broadly, we want to push forward to a world where TBD does not have the only, or final say on any Web5 decision: **decentralization is a strength in the development of Web5**.\n\nThis transition is only made possible by active engagement from the community. It is the reason our code is open, and we have set up avenues for engagement. We look towards the community to engage with TBD and others, and push for the future we wish to see built.\n\n## Software Vision\n\n**TBD is fostering a set of community-driven, open source, standards-based software to facilitate Self Sovereign Identity on Web5.**\n\nWe want to realize the vision of the Web5 community: *to build pragmatic standards-based software that serves a wide variety of needs*. The software shall not be tied to any specific entity, nor, without good reason, exclude possibilities within the SSI space. Balancing both feature-richness and complexity we must work closely with our users to design software that meets the needs of all who wish to be on Web5. We think in terms of toolkits, composed of the purpose-specific tools in them. These toolkits exist in a hierarchy of abstractions from which powerful, intuitive, and human-centric software can be built.\n\nThe software must be designed in a flexible, modular manner. This means interfaces that feature a default implementation or two, but can be extended to facilitate integration into many systems (e.g. swapping out databases, encryption methods, credential formats as needed). The software is intended to be built on open standards in the SSI space. The standards space is fast-changing and there may be cases where we use ill-defined and ill-supported standards; we must be able to favor practicality and working implementations over robust standards with a commitment to see the standards through. There may be cases where we use our software to innovate past the current state of these standards and open the opportunity to contribute back to existing standards and standards bodies.\n\nWe recognize that the SSI ecosystem is full of competing and developing standards. Often this can feel like developing against a set of moving targets and promises of feature sets. There’s a lot of information to grok and everyone has an opinion—this is a good thing! It can be difficult to pick winners, and even more difficult to choose between multiple standards that appear to do the same thing: we do not want to create a Swiss Army knife that contains five different types of scissors, we’d rather it contain one (or maybe two) scissors that get the job done well 99% of the time. We favor evaluating the addition of features and standards on a case-by-case basis, and looking towards implementations of standards and features that are well-reasoned, with committed developers. Bonus points if there is already demonstrated usage and interoperability.\n\nWe also recognize that the SSI ecosystem uses a wide set of tools, languages, and technologies: working across web browsers, mobile applications, backend servers, ledgers, and more. For languages we’ve started with [Go](https://go.dev/) (for the SSI SDK and SSI Service) because of its robust cryptographic support, speed, ability to be compiled to [WASM](https://webassembly.org/), and, above all else, simplicity. It is crucial that the code we write is approachable to encourage contribution. Simple and clear is always preferred over clever. The future is multi-language, and multi-platform. We welcome initiatives for improving multi-language and multi-platform support, and are open to fostering them into our GitHub organization.\n\n## SSI SDK\n\nNamed `ssi-sdk`, this SDK encapsulates a set of standards related to [Self Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html). The `ssi-sdk` intends to provide flexible functionality based on a set of standards-based primitives for building decentralized identity applications in a modular manner: with limited dependencies between components.\n\nPrimarily, the SDK serves to support Decentralized Identifiers and Verifiable Credentials and their associated standards. Interacting with Decentralized Identifiers: resolving identifiers, signing, verifying, encrypting, and decrypting data using cryptographic keys found in DID Documents. Interacting with Verifiable Credentials: creating and using data schemas, facilitating credential application, issuance, and exchange.\n\nThe SDK is an active work in progress, and can be found on the [TBD GitHub](https://github.com/TBD54566975/ssi-sdk).\n\n## SSI Service\n\nThe Self Sovereign Identity Service (SSIS) facilitates all things relating to [DIDs](https://www.w3.org/TR/did-core/) and [Verifiable Credentials](https://www.w3.org/TR/vc-data-model) — in a box! The service is a part of a larger [Decentralized Web Platform](https://developer.tbd.website/projects/web5) architecture. The SSI Service is a JSON-API web service that wraps the [ssi-sdk](https://github.com/TBD54566975/ssi-sdk) to facilitate user-focused interactions on Web5. The service is intended to interact with user interfaces, wallets, decentralized web nodes, and other web infrastructure. \n\nBy taking the lower-level building blocks exposed by the SDK, the service is intended to drastically lower the barrier to entry for any individual or organization interesting in building on the Web5 stack. Like the SDK, it is agnostic to any specific business or use case, and design to be pluggable into external infrastructure whether existing or new. \n\nThe service is assumed to be run by a single organization and assumes external authentication and authorization. The service assumes no infrastructure requirements and is flexible to multiple deployment models, databases, key management solutions, and user interfaces. We expect that a wide array of users and use cases will use and build on top of the service, creating layers of abstraction and intermediation for processing business logic, handling user accounts, and so on.\n\nThe service is an active work in progress, and can be found on the [TBD GitHub](https://github.com/TBD54566975/ssi-service).\n\n## How Features are Developed\n\nWe are in the early days of Web5. By intention, we’ve announced our ideas and projects way before they are ready for an alpha release, let alone inclusion in a production-ready application. Transparency is an asset in sharing our thinking and gaining mindshare for what we are building. As such, there are many forks in the road fast-approaching. To move past these forks, and the forks after those I introduce some light process to guide principled decision making:\n\n1. Features shall be developed using the [Socratic method](https://en.wikipedia.org/wiki/Socratic_method): making statements, interrogating them, asking *whys* and *hows*, being intellectually honest with risk, uncertainty, consider second, third and n-order effects.\n2. All new feature proposals shall include a light design document outlining desired functionality, end-user utility, prior art, room for improvement and next steps, risks and mitigations, considerations, and open questions.\n3. A quorum of project maintainers shall review and progress feature proposals in a timely manner.\n\nTemplates for the aforementioned process have been created on each GitHub repository. I encourage you to create GitHub issues and Forum discussions to explore thinking, and revise designs before going forth with a contribution.\n\nFor templates on feature development, philosophies on versioning and releases, and more information view our GitHub documentation: \n\n[SSI Service GitHub Docs](https://github.com/TBD54566975/ssi-service) | [SSI SDK GitHub Docs](https://github.com/TBD54566975/ssi-sdk)\n\n## The Goal\n\nI believe in setting public and ambitious *measurable* goals. This serves as a powerful self-discipline mechanism, as well as a call to action for forward progress. Officially the [timeline for Web5 can be found on our site](https://developer.tbd.website/blog/web5-roadmap). Unofficially, here is my ambition:\n\n**By January 1st 2023 the following shall be true:**\n\n- The first beta release of the SSI SDK and SSI Service (0.1.0) will be released.\n- Each SSI project will have >75% test coverage.\n- Each project will have robust user and developer documentation with clear examples.\n- The SSI SDK will have feature complete specification implementations for at least all fifteen standards identified above.\n- The SSI Service will be deployable in an infrastructure-agnostic manner, demonstrated on ≥ 2 platforms.\n- The SSI Service will facilitate practical end-user flows facilitating:\n    - Creating and managing DIDs using ≥ 2 DID methods\n    - Creating and issuing Verifiable Credentials backed by JSON schemas\n    - Creating Credential Manifests, accepting Credential Applications, and fulfilling Credential Applications\n    - Creating Presentation Definitions, sending Presentation Requests, and accepting Presentation Submissions\n    - Creating Credential Revocations and checking Credentials against them\n    - Creating and processing Trust Establishment documents\n- The SSI SDK and Service will support the Decentralized Web Node specification and the Service will work with at least one DWN.\n\n## Parting Thoughts\n\nYou should now have a pretty good sense of how we conceive of SSI software on Web5, and how its journey will unfold. Most importantly the mission is not TBD’s alone, it is that of the community. We build real software for real people and favor pragmatism above all else. What I’ve written here is *current thinking* and is always subject to evolution—with your help. I’m looking forward to you joining us in pushing SSI and Web5 forward, gaining new perspectives, solving new use-cases, and building some cool shit."
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:          "content": "<head>\n  <title>What are Verifiable Credentials?</title>\n  <meta name=\"description\" content=\"What are verifiable credentials, who issues them, and how do they get verified\" />\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/what-are-verifiable-credentials\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"What are Verifiable Credentials?\" />\n  <meta property=\"og:description\" content=\"What are verifiable credentials, who issues them, and how do they get verified\" />\n  <meta property=\"og:image\" content=\"https://developer.tbd.website/assets/images/what_are_vcs_banner-1ec4bea6c245b62b76685a338d5f8d63.png\" />\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/what-are-verifiable-credentials\" />\n  <meta name=\"twitter:title\" content=\"What are Verifiable Credentials?\" />\n  <meta name=\"twitter:description\" content=\"What are Verifiable Credentials, who issues them, and how do they get verified\" />\n  <meta name=\"twitter:image\" content=\"https://developer.tbd.website/assets/images/what_are_vcs_banner-1ec4bea6c245b62b76685a338d5f8d63.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![What Are Verifiable Credentials](/img/what_are_vcs_banner.png)\n\nWhen you hear the term 'credential', what comes to mind? Is it a driver's license, passport,  birth certificate, college degree, state ID? The common thread of these forms of credentials is that they are physical items, verified by recognized centralized bodies like a government agency or accredited university.  \n\nSo how do credentials translate into the digital world where within a few clicks someone can make a fictitious identity? Introducing... **verifiable credentials** (VCs), a digitally signed electronic credential that follows an [open standard](https://www.w3.org/TR/vc-data-model/) that lets you create, own, and manage your credentials across a variety of platforms.\n\n<!--truncate-->\n\n## Why Do We Need Verifiable Credentials?\n\nOver the course of your digital history, you've likely signed up for hundreds of apps and services with elements of your personal data fragmented, such as your name, email address, or more sensitive information like your date of birth and government ID number. These services then share your data with other third parties that you may not even be aware of - with or without your consent. It's difficult to go back and deactivate your profiles, delete your accounts, or reclaim additional data these services have collected on you. Worse is if there is a data breach in one of these services and now your data is out in the public.\n\nVerifiable Credentials aim to solve these problems by putting the power to manage your data back into your hands. Imagine being able to own and control your personal data by only allowing access to services that require it and having the authority to disable services that no longer need it. You can even manage your data on your own self-hosted decentralized web node via an identity hub without relying on any centralized third party. \n\nAdditionally, you can own multiple Verifiable Credentials for various use cases such as a student ID, a driver's license, a passport, or a certificate you earned. You can also have one specific Verifiable Credential with multiple [presentation layers](https://www.w3.org/TR/vc-data-model/#presentations) such as a passport where certain metadata is presented when used in a given context.\n\n## How Do Verifiable Credentials Work?\n\nYou may be wondering who actually issues a Verifiable Credential, how does it get verified and who verifies the verifier? \n\nLet's look at the following example of the manual way credentials are issued. You've been accepted to your top university of choice and now need a student ID to access both the campus and online resources. Specifically, you want to apply for a campus parking permit as well. \n\nTypically this process would involve you taking physical copies of multiple forms of ID verification such as a passport, birth certificate, and driver's license to a physical office. Then after a few days of various checks, you're finally issued a physical student ID card from that university. The university trusts the entity that issued your birth certificate, passport, and driver's license to create a student ID for you. They can even look you up by the identification numbers on these documents. \n\nBut what if someone in the admissions office looked up your driver's license and noticed those parking tickets you have? Were they even allowed to do so and could this bias their decision to give you a parking permit?\n\nThe current process looks something like this:\n\n![Issuing a Student ID manually](/img/issue_student_id_manually.png)\n\n\nNow let’s look at how verifiable credentials could help in this scenario. The university would run verification checks for each document provided (passport, driver’s license, birth certificate, etc) and the credential would be limited to just basic bio data that is required such as a legal name, date of birth, etc. So no one from the student department will be able to see your ticketing history associated with your driver’s license.\n\n![Issuing a Student ID as a Verifiable Credential](/img/issue_vc_for_student_id.png)\n\n\n## Using Verified Credentials \n\nDecentralized identifiers (DIDs) work alongside Verifiable Credentials. DIDs are unique identifiers that let us reference various VCs and the entities that also issue those credentials. For example a government or company can have their own unique DID. \n\n**DIDs use the following schema:**\n\n![did:example:12345abcde](/img/did-format.png) \n*photo credit: W3C*\n\nDIDs can then be used to create a Verified Credential by digitally signing it and assigning it to a holder, similar to how transactions are cryptographically signed in a blockchain. Depending on the signature format of the credential, the holder (also known as a DID subject) can then choose how much of that credential they want to present to an entity requesting the credential, which is referred to as selective disclosure. \n\nAn example is an employer, Company X, who looks up the DID of your college diploma from University Y. \n\nCompany X queries the issuer of your Diploma Verifiable Credential, in this case University Y, and also looks up the DID of that university in a verifiable data registry (VDR). Think of VDRs as just lists that can be managed and maintained by various parties such as wallets, financial institutions, DAOs, non-profits, etc. If your credentials have valid digital signatures but somehow University Y is on a list of non-accredited institutions in the USA but accredited institutions in Europe, it would be up to the Company X to decide if they want to accept it.\n\nThe diagram below outlines the flow of this process.\n\n![issuer issues a verifiable credential to a holder who can send a presentation of their VC to a verifier](/img/vc_ecosystem.svg)\n*photo credit: W3C*\n\n\n## Use Cases for Verifiable Credentials\n\nThere are several use cases that can be realized with the use of Verifiable Credentials, such as\n\n- Employment checks without being invasive \n- Managing of health records, land titles, etc\n- Managing of various forms of personal identification such as passports, driver’s licenses, etc \n- KYC (Know Your Customer) checks for financial institutions and businesses\n- Managing your gamer profile across different metaverses\n- Managing Memberships\n\nDIDs and VCs allow us to create identities and credentials in an interoperable ecosystem that allow developers and businesses to build a new wave of products, applications, and services that put users in control."
./.docusaurus/docusaurus-plugin-debug/default/docusaurus-debug-all-content-673.json:          "content": "<head>\n  <meta property=\"og:title\" content=\"What is Web5?\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:url\" content='https://developer.tbd.website/blog/2022-07-01-what-is-web5' />\n  <meta name=\"og:description\" content=\"Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\" />\n  <meta property=\"og:image\" content=\"/img/what_is_web5.png\" /> \n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta name=\"twitter:site\" content=\"@tbddev\" />\n  <meta name=\"twitter:title\" content=\"What is Web5\" />\n  <meta property=\"twitter:url\" content='https://developer.tbd.website/blog/2022-07-01-what-is-web5' /> \n  <meta name=\"twitter:description\" content=\"Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\" />\n  <meta name=\"twitter:image\" content=\"/img/what_is_web5.png\" />\n\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n![What is Web5?](/img/what_is_web5.png)\n\nWeb 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\n\nIn the current web model, users do not own their data or identity. They are given accounts by companies and their data is held captive in app silos. To create a new class of decentralized apps and protocols that put individuals at the center, we must empower them with self-owned identity and restore control over their data.\n\n<!--truncate-->\n\nThis platform embraces the convenience of Web 2 but it also returns control back to the users, an ethos of Web 3. The harmony of these two views is what we're calling Web 5.\n\n![{Web 2}{Web 3} -> {Web 5}](/img/web5-graphic.png)\n\n## Components of Web 5\n\nThere are three main pillars of the decentralized web platform, all of which are based on open standards.\n\n![The pillars of Web5 are Decentralized Identifiers (self-owned identifiers that enable decentralized identity authentication and routing), Verifiable Credentials (data formats and models for cryptographic presentation and verification of claims), and Decentralized Web Nodes (data storage and message relay nodes that serve as the foundation for decentralized apps and protocols).](/img/pillars-of-web5.png)\n\n## Decentralized Identifiers\n\nThe identifiers we know and use today are owned by the government, a company, an organization, or some other intermediary. For example, our email addresses and social media handles are identifiers associated with us but are owned and controlled by the service providers. These companies have the right to ban, disable, or delete these identifiers and we have little to no control over this.\n\nSo before we can realize truly decentralized applications, we need decentralized identifiers that users own and control. This removes the dependency on centralized entities to authenticate and represent us.\n\n[Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DIDs) are a W3C standard. They have a standardized structure that essentially links to you and your information.\n\n![A DID is comprised of three parts: Scheme, DID Method, and DID Method Specific String](/img/did-example.png)\n\nThey are a long string of text that consists of three parts:\n\n- the URI scheme identifier, which is did\n- the identifier for a [DID method](https://www.w3.org/TR/did-core/#dfn-did-methods)\n- the DID method-specific identifier\n\nStoring DIDs on [ION](https://identity.foundation/ion/) (a Layer 2 DID network that runs on top of Bitcoin) is a preferred design decision for the implementation of Web 5. ION is a decentralized replacement for DNS for identity identifiers, so there are no authorities, coordinators, tokens, or other centralized bottleneck.\n\n**DIDs are the only component of Web5 that touch a blockchain**, which is generally limited to anchoring the keys/endpoints linked to the ID.\n\nThat being said, anchoring DIDs on Bitcoin (or any blockchain) is not a requirement. In fact, what's great about having the standardized formatting for DIDs is that they can be anchored anywhere or not anchored at all and this still works, although with varying levels of decentralization.\n\nHere are examples of DIDs on the Bitcoin blockchain, the Ethereum blockchain, and the web. Notice they all use the same format: scheme, DID method, and DID method-specific identifier.\n\n```json\ndid:btcr:xyv2-xzpq-q9wa-p7t\ndid:ens:some.eth\ndid:web:example.com\n```\n\nBecause personal data is not stored on the blockchain, the DID essentially acts as a URI that associates the subject of the DID (the person, company, or object being identified) with a DID document that lives off-chain.\n\nDID Documents are JSON files stored in decentralized storage systems such as IPFS, and describe how to interact with the DID subject. The DID Document contains things like the DID subject's public keys, authentication and verification methods, and service endpoints that reference the locations of the subject’s data.\n\n```json\n{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\",\n  \"verificationMethod\": [\n    {\n      \"id\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\",\n      \"type\": \"Secp256k1VerificationKey2018\",\n      \"controller\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\"\n    }\n  ],\n  \"authentication\": [\"did:ion:EiClkZMDxPKqC9c-umQfTkR8\"]\n}\n```\n\n## Verifiable Credentials\n\n[Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) are a fully ratified W3C standard that work hand in hand with Decentralized Identifiers to enable trustless interactions - meaning two parties do not need to trust one another to engage, but claims made about a DID subject can be verified.\n\nFor example, Alice needs to prove she has a bank account at Acme Bank. Acme Bank issues a cryptographically signed Verifiable Credential which would be stored in Alice's identity wallet.\n\n![Illustration of Acme Bank issuing a verifiable credential to Alice’s wallet, and the wallet presenting the credential as proof of a bank account to a PFI Verifier.](/img/acme-bank-example.png)\n\nThe credential contains the issuer as Acme and the subject as Alice, as well as the claims, which are Alice's account number and full name.\n\nUpon request for proof of banking, Alice presents the Verifiable Credential that's cryptographically signed by both Alice as well as her bank.\n\nThis is an easy, machine-readable way to share credentials across the web. The Verifier does not know or trust Alice, but they do consider Acme trustworthy, and they have essentially vouched for Alice therefore distributing trust.\n\n## Decentralized Web Nodes\n\nToday, centralized entities act as our data stores. Applications hold all of our content and preferences on their servers.\n\n[Decentralized Web Nodes](https://identity.foundation/decentralized-web-node/spec/) (DWNs) change this by allowing us to decouple our data from the applications that we use, and instead host our data ourselves in our own personal data stores.\n\n[BlueSky](https://blueskyweb.xyz/) is a good example; it's a decentralized version of Twitter that's in the works. With BlueSky, your tweets and your connections aren't stored with the application. They are stored with you. So you can present your content on any decentralized social media app you want, not just BlueSky.\n\nYour DWNs can hold both public and encrypted data. For example, in the case of a decentralized version of Twitter, you'd want data like your tweets and your connections to be public but things like your DMs to be private.\n\n**Your decentralized web nodes do not live on the blockchain**. You can host your web nodes anywhere (your phone, computer, etc) and can replicate them across your devices and clouds and all data will be synced.\n\n![Decentralized Web Nodes is an emerging standard for data storage and relay that enables entities of any type (people, organizations, etc) to send and store encrypted or public messages and data, enabling a wide variety of decentralized apps and protocols to be built on top. Features of Decentralized Web Nodes include: universally addressable, replicated, secure, semantic discovery, async message threads, supports any identity type.](/img/features-graphic.png)\n\nWhile self-hosting your DWNs provides a means for decentralizing your data, we recognize some users will be more comfortable with others hosting their web nodes for convenience sake. We envision there will be vendors offering to host your web nodes for you. The good part about that is you can encrypt any private data so unlike today where cloud hosts can scan everything that you host there, you can still maintain some privacy even if you have your web nodes hosted by intermediaries.\n\nYour DWNs are associated with your Decentralized Identifiers and are listed in a DID document.\n\nNotice the `serviceEndpoint` section of the DID doc specifies service endpoints and provides URIs to the decentralized web nodes.\n\n```json\n{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:web:example.com:u:alice\",\n  \"service\": [\n    {\n      \"id\": \"#dwn\",\n      \"type\": \"DecentralizedWebNode\",\n      //highlight-start\n      \"serviceEndpoint\": {\n        \"nodes\": [\"https://dwn.example.com\", \"00:11:22:33:FF:EE\"]\n      }\n      //highlight-end\n    }\n  ],\n  \"verificationMethod\": [\n    {\n      \"id\": \"did:web:example.com:u:alice\",\n      \"type\": \"Secp256k1VerificationKey2018\",\n      \"controller\": \"did:web:example.com:u:alice\"\n    }\n  ],\n  \"authentication\": [\"did:web:example.com:u:alice\"]\n}\n```\n\nGiven an application has the address to your DWN, they can send you a request for data.\n\nThis represents a request from an application to obtain all objects within a DWN that follow the `SocialMediaPosting` schema:\n\n```json\n    POST https://dwn.example.com/\n    BODY {\n      \"requestId\": \"c5784162-84af-4aab-aff5-f1f8438dfc3d\",\n      \"target\": \"did:example:123\",\n      \"messages\": [\n        {\n          \"descriptor\": {\n            \"method\": \"CollectionsQuery\",\n            \"schema\": \"https://schema.org/SocialMediaPosting\"\n          }\n        },\n        {...}\n      ]\n    }\n```\n\nThe data within DWNs are JSON objects that follow a universal standard, thus making it possible for any application to discover and process the data given its semantic type.\n\nIf this data is public, those objects will be automatically returned to the application, and if the data is private, the node owner would need to grant the application access to that data.\n\n## Identity Wallets\n\nObviously all of this is pretty complicated, especially for non-technical users. So we need a simplistic, easy to use interface that will allow people to access and manage their identity.\n\nA well designed identity wallet would provide ways to manage the data stored in decentralized web nodes, the decentralized IDs and the context in which they should be used, verifiable credentials, and authorizations.\n\n![Identity wallets are mobile apps that provide UI and functionality to manage credentials and app data stored in Decentralized Web Nodes; sign, verify, discover, and present credentials to verifying parties; perform authentication and manage authorizations; support create, update, and recovery of DIDs across all supported DID Methods; maintain and enforce which DIDs are used with different people, apps, and services.](/img/identity-wallets.png)\n\n## Decentralized Web Apps\n\nWeb 5 enables developers to build decentralized web applications (DWAs) on top of it and it’s all open source! You're free to use it as your foundation and focus your attention on what you really care about, your app. Web5 brings to DWAs what cloud and application servers bring to enterprise apps. It does the hard part. It brings decentralization. By building your apps on top of Web 5, you get decentralization and identity and data management as part of the platform.\n\nThis is definitely a fundamental change in how we exchange data, but it's not a total overhaul of the web we already know. This works like Progressive Web Apps, but you'd add the decentralized web node SDK and then applications are free to really go serverless because the data isn't stored with them.\n\n![Illustration of PWAs compared to DWAs. PWAs comprise of a web app that uses a service worker to pull from local cache and a centralized app server; whereas DWAs comprise of a DWN SDK and a service worker that pull from local cache and Decentralized Web Nodes.](/img/pwa-dwa.png)\n\nThe sky's the limit to what you can build on top of this platform, but here are some cool basic examples.\n\n## Music Applications\n\nNo one likes recreating their music playlists over and over again for different apps. With Web 5, you wouldn't have to do that.\n\nIn this example, Groove has access to write to Alice's decentralized web node and adds a new entry.\n\nTidal has access to read from Alice's DWN, so can read the new entry that was added by Groove, and now Alice has her playlist readily available on both apps.\n\n![Illustration of Groove writing a new schema.org/MusicPlaylist object to Alice’s remote DWN and Tidal, who has read ability, reading the MusicPlaylist entry that Groove added.](/img/music-to-my-ears.png)\n\nWith the continuous utilization of the data across apps, not only do Groove and Tidal get access to Alice's data, but they use it to improve her user experience, thus creating a stronger experience than Alice could have ever gotten had she not used this tech.\n\n## Travel Applications\n\nYour travel preferences, tickets, and reservations are scattered across so many different hotels, airlines, rental car agencies and travel apps, making it really difficult to coordinate. Heaven forbid there's any hiccup in the system such as a delayed flight. You end up trying to get in touch with the car rental place to let them know you'll be late for your reservation, and if it's really late, you'd want to call the hotel to ask them not to give away your room. All while you're hustling and bustling at the airport.\n\nWeb 5 can help unify these various app experiences.\n\nIf Alice gives the hotel, the airline, and the rental car agency access to the `Reservation` and `Trip` objects in her DWN, they can react and adjust accordingly to any changes made.\n\n![Illustration: Alice grants her hotel, airline, and rental car provider the ability to add schema.org/Reservation objects to her collection of trip-related data and also grants any app she chooses access to reservations and tickets stored in her schema.org/Trip data to help her visualize her itinerary.](/img/hotel-travel-plans.png)\n\nThese are just a few applications that can be realized by building on top of Web 5. There's so many more possibilities once the web is truly decentralized the way it was always intended to be.\n\n## How to Get Involved\n\nWhile we’re super excited about this technology, there's still lots of problems to be solved. We welcome you to join us in making the web we all deserve.\n\n- Check out our [GitHub projects](https://github.com/TBD54566975/collaboration/blob/main/projects/GETTING_STARTED_DWP.md), if you’d like to see more or contribute to the components.\n\n- We have [open job reqs](https://www.tbd.website/careers) if you’re interested in formally working on decentralized technologies.\n\n- If you're a company who is trying to solve these same challenges or could make use of any of these components, [we'd love to collaborate](https://www.tbd.website/connect).\n\n- If you’d like to join the community, we’re on [Discord](https://discord.gg/tbd)."
./.docusaurus/routesChunkNames.json:  "/learn/discussions/blockchain-crypto-tbd-cb6": {
./.docusaurus/routesChunkNames.json:    "content": "content---learn-discussions-blockchain-crypto-tbd-8-eb-449"
./.docusaurus/globalData.json:              "id": "discussions/blockchain-crypto-tbd",
./.docusaurus/globalData.json:              "path": "/learn/discussions/blockchain-crypto-tbd",
./.docusaurus/routes.js:        path: '/learn/discussions/blockchain-crypto-tbd',
./.docusaurus/routes.js:        component: ComponentCreator('/learn/discussions/blockchain-crypto-tbd','cb6'),
./.docusaurus/docusaurus.config.js:        "content": "tbd, tbdex, decentralized identifiers, decentralized ids, verifiable credentials, dwp, decentralized web platform, decentralized web nodes, web5, web3, open source, decentralized bitcoin, decentralized crypto, decentralized exchange, decentralized exchanges, decentralized, defi, decentralized finance"
./.docusaurus/docusaurus-plugin-content-docs/learn/version-current-metadata-prop-751.json:            "href": "/learn/discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/version-current-metadata-prop-751.json:              "thumbnail": "/img/learn/blockchain_crypto_tbd.png"
./.docusaurus/docusaurus-plugin-content-docs/learn/version-current-metadata-prop-751.json:            "docId": "discussions/blockchain-crypto-tbd"
./.docusaurus/docusaurus-plugin-content-docs/learn/version-current-metadata-prop-751.json:    "discussions/blockchain-crypto-tbd": {
./.docusaurus/docusaurus-plugin-content-docs/learn/version-current-metadata-prop-751.json:      "id": "discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:  "unversionedId": "discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:  "id": "discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:  "source": "@site/learn/discussions/blockchain-crypto-tbd.mdx",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:  "slug": "/discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:  "permalink": "/learn/discussions/blockchain-crypto-tbd",
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-blockchain-crypto-tbd-mdx-8eb.json:      "thumbnail": "/img/learn/blockchain_crypto_tbd.png"
./.docusaurus/docusaurus-plugin-content-docs/learn/site-learn-discussions-history-of-blockchains-mdx-0af.json:    "permalink": "/learn/discussions/blockchain-crypto-tbd"
./.docusaurus/docusaurus-plugin-content-blog/default/blog-archive-80c.json:      "content": "<head>\n  <meta property=\"og:title\" content=\"Web Assembly with ChatGPT\" />\n  <meta property=\"og:url\" content='https://developer.tbd.website/blog/chatgpt-writingcode' />\n   <meta name=\"twitter:card\" content=\"summary\" />\n  <meta name=\"twitter:site\" content=\"@tbddev\" />\n  <meta name=\"twitter:title\" content=\"Web Assembly with ChatGPT\" />\n  <meta name=\"twitter:description\" content=\"Using ChatGPT to help add WASM support to the self-soverign identity SDK\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n\n## Web Assembly\n\n[Web Assembly](https://webassembly.org/) is a popular format for running binary applications in web browsers (with wide support).\n\nThis can have a few advantages but the interesting thing for us is that this can allow sharing of implementations of functionality: eg credential issuance, DID resolving, cryptographic funcitons etc which you may not want to necessarily re-implement in javascript or typescript.\n\nThe [SSI-SDK](https://github.com/TBD54566975/ssi-sdk) is an implementation of a lot of standards for self soverign identity, so it is a great candidate to expose via WASM to web apps. \n\nNow there is a whole lot of (lets face it: tedioius) machinery to get wasm to be compiled from go (ok if you are really curious you can [read the code](https://github.com/TBD54566975/ssi-sdk/pull/265/)), but the upshot of it is that there is a .wasm file produced which when consumed in just the right way in a web page, allows you to call functions from javascript, that look and feel like javascript, but are actually running in the web-assembly machiner (and compiled down from golang).\n\nSay you had a function in golang land which looked like this: \n\n```golang \n// Resolve attempts to resolve a DID for a given method\nfunc (dr Resolver) Resolve(did string, opts ...ResolutionOptions) (*DIDResolutionResult, error) {\n  ...\n```\n\nYou could call it from the web via:\n```javascript\nconsole.log(resolveDid(\"did:peer:0z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH\"));\n```\n\nand it would Just Work thanks to WASM! \nWell, thanks to WASM and a lot of boring glue. \n\n\n## ChatGPT\n\nBut the boring glue is what I am hear to talk about it, as it turns out ChatGPT can be quite helpful for the boring (but important) glue. \n\n(If you have been under a rock and haven't heard of ChatGPT - google it now and then come back)\n\nSo firstly, there is some work to be done to build a shim between the JS type world and the Golang type world: \n\n```golang\n// 1. Simplest function - note we wrap things with js.ValueOf (if a primitive you don't technically need to)\nfunc sayHello(_ js.Value, args []js.Value) interface{} {\n\treturn js.ValueOf(\"Hello from golang via wasm!\")\n}\n```\n\nThis gets more complicated when you have more complicated types, but essentially this is the pattern you follow to expose functionality. \nNow I am a pretty ordinary golang developer, so being lazy I thought I would see if I could teach ChatGPT about WASM and if it could write this glue code for me. \n\nHelpfully the ssi-sdk has a good amount of test coverage, so to teach ChatCPT about the api I was trying to expose, I pasted in a test case which exercised the api. \nThe functionality was the \"Resolve\" function above, and the test code showed how to use it. \n\nI then asked ChatGPT to provide a WASM friendly wrapper for that functionality:\n\n\n![chatgpt generated resolver](/img/chatgpt_resolver.png)\n\nTo do this, I gave it an example of some previously written code that uses some (unrelated) functionality and also exposes it to WASM. \nAs yoyu can see it was happy to provide an implementation which whilst close, with some minor tweaking. \n\nI was able to tidy it up and include it in the [pull request](https://github.com/TBD54566975/ssi-sdk/pull/265). Handy - thanks ChatGPT!\nMoreover, as I am an ordinary golang developer I was able to ask it to put in a retry on error (also some important glue) when using WASM from a web app (this staved a minor amount of googling): \n\n\n![chatgpt generated error handler](/img/chatgpt_error.png)\n\n\n## Parting thoughts\n\nWASM seems surpremely useful, and ChatGPT, while terrifying on one level, looks like it can really take away some of the grind work from developers, allowing us to move much faster into more platforms. And no, this post was NOT written by ChatGPT, but by a human."
./.docusaurus/docusaurus-plugin-content-blog/default/blog-archive-80c.json:      "content": "<head>\n  <title>TBD Partners with Circle!</title>\n  <meta name=\"description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/tbd-circle-partnership\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"TBD Partners with Circle!\" />\n  <meta property=\"og:description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n  <meta property=\"og:image\" content=\"/img/tbd_circle_partnership.png\" />\n\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/tbd-circle-partnership\" />\n  <meta name=\"twitter:title\" content=\"TBD Partners with Circle!\" />\n  <meta name=\"twitter:description\" content=\"TBD and Circle are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications.\" />\n  <meta name=\"twitter:image\" content=\"/img/tbd_circle_partnership.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![TBD Partners with Circle!](/img/tbd_circle_partnership.png)\n\nTBD and [Circle](https://www.circle.com/en/?_gl=1*14yjcwp*_up*MQ..&gclid=CjwKCAjwm8WZBhBUEiwA178UnPZbgZJJxhwK7ivE5Yx9FGW8PQ31-hc1O-njcLOmzcN2nzLz110FihoCgV4QAvD_BwE) are collaborating on a set of open standards and open source technologies aimed at enabling global-scale, mainstream adoption of digital currency in payments and financial applications. The first step of which will support cross-border remittances and self-custody wallets that can hold stablecoins.\n\n<!--truncate-->\n\n\nWe are supporting USDC with an eye on a number of use cases that make it easy for developers to build on top of Block’s [tbDEX protocol](https://developer.tbd.website/projects/tbdex) and its [Web5](https://developer.tbd.website/blog/what-is-web5) decentralized identity platform.  \n\nThese use cases include:\n\n\n\n* Ubiquitous global on-and-off-ramps that connect traditional payments rails to digital assets, making it easier and more accessible for consumers and businesses around the world to benefit from the crypto economy.\n\n* Faster, lower cost remittances globally – starting from the U.S. to Mexico.\n\n* Self-custody wallets that can hold stablecoins – U.S. dollar denominated stablecoins – to provide a store of value to individuals in countries who must balance limited access to U.S. dollars with hyperinflationary environments.\n\nAn open approach solves for decentralized identity and enables safe, scaleable, and frictionless payments to work for consumers and merchants using stablecoins. \n\nThis partnership aims to make a significant impact on peoples’ everyday financial lives. It both fuels the potential for crypto to emerge as a mainstream payments system while establishing decentralized identity as the model for building trust in a scalable and privacy-preserving way.\n\nStay updated on our efforts here and connect with us [@tbd54566975](https://twitter.com/TBD54566975)."
./.docusaurus/docusaurus-plugin-content-blog/default/blog-archive-80c.json:      "content": "<head>\n  <title>Self Sovereign Identity, TBD, and Web5</title>\n  <meta name=\"description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/ssi-tbd-web5\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"Self Sovereign Identity, TBD, and Web5\" />\n  <meta property=\"og:description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n  <meta property=\"og:image\" content=\"https://developer.tbd.website/assets/images/ssi_tbd_web5-362c244c231552618f4e9abd2d4482c7.png\" />\n\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/ssi-tbd-web5\" />\n  <meta name=\"twitter:title\" content=\"Self Sovereign Identity, TBD, and Web5\" />\n  <meta name=\"twitter:description\" content=\"How TBD is building standards-based open source software towards the goals of SSI and Web5\" />\n  <meta name=\"twitter:image\" content=\"https://developer.tbd.website/assets/images/ssi_tbd_web5-362c244c231552618f4e9abd2d4482c7.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![Self Sovereign Identity, TBD, and Web5](/img/ssi_tbd_web5.png)\n\nSelf Sovereign Identity (SSI) is an umbrella term well-detailed by Christopher Allen, and inspired by many in the Identity community before him, in his 2016 blog post: [*The Path to Self-Sovereign Identity*](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html), which identifies *Ten Principles of Self-Sovereign Identity:*\n\n<!--truncate-->\n\n1. **Existence.** *Users must have an independent existence.*\n2. **Control.** *Users must control their identities.*\n3. **Access.** *Users must have access to their own data.*\n4. **Transparency**. *Systems and algorithms must be transparent.*\n5. **Persistence.** *Identities must be long-lived.*\n6. **Portability.** *Information and services about identity must be transportable.*\n7. **Interoperability.** *Identities should be as widely usable as possible.*\n8. **Consent.** *Users must agree to the use of their identity.*\n9. **Minimalization.** *Disclosure of claims must be minimized.*\n10. **Protection.** *The rights of users must be protected.*\n\n\n\nSince 2016, a lot has happened! There have been a flurry of conventions, discussions, papers, standards, software, and industry wide adoption of technology based on the principles of SSI. The space is at its most mature, and only growing.\n\n[Block](https://squareup.com/us/en/press/square-changes-name-to-block)’s mission is economic empowerment. Historically, this has looked like building products and offering services such as [Square](https://squareup.com/), enabling millions of merchants _to take payments, manage staff, and conduct business in-store and online_, and [CashApp](https://cash.app/), which enables millions, especially the un and under-banked to send, spend, bank, and invest their money (and Bitcoin!). When [TBD](https://www.tbd.website/), a new business unit at [Block](https://block.xyz/) formed in 2021, we expanded on Block’s mission, setting out to help create _a decentralized future that returns ownership and control over your finances, data, and identity_. TBD’s mission is strongly aligned with the principles of SSI.\n\nTo facilitate our mission, TBD launched [Web5](https://developer.tbd.website/blog/what-is-web5): a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols. Web5 takes SSI concepts, standards, and software and provides them as an opinionated bundle to enable all that self sovereignty and digital identity has to offer. What TBD is building for Web5 has a number of components today, and more tomorrow. Among those are the Self Sovereign Identity SDK and Self Sovereign Identity Service (SSI SDK, and SSI Service), Decentralized Web Nodes (DWN), and Identity Wallets. At the time of writing, all of these components are under active development. This was an intentional move by the team to adopt an ‘open-by-default’ model, and include the community in the development of Web5 from the beginning.\n\nHere we’ll lay out the vision for a key component of Web5: Self Sovereign Identity. Specifically, how we at TBD are building standards based software in a community towards the goals of SSI and Web5. The two “SSI” named projects — the SSI Service and SSI SDK — sit along side Decentralized Web Nodes, Identity Wallets, User Interfaces, and much more — but focus on a set of standards-based building blocks of the Web5 stack.\n\n## Software Mission\n\n**TBD is developing open source, standards-based software to facilitate Self Sovereign Identity on Web5.**\n\n### Open Standards\n\nThe vision of SSI is realized via [Open Standards](https://en.wikipedia.org/wiki/Open_standard#:~:text=%22Open%20Standards%22%20are%20standards%20made,are%20intended%20for%20widespread%20adoption.). Crucially, these standards are accessible to all: to view and to contribute. You may not be aware of it, but you interact with Open Standards every day: whether via web browsers, hardware you use and their underlying protocols, programming languages, audio files, internet and bluetooth devices, text documents, chat applications, encryption you use and so much more. Open Standards facilitate nearly every aspect of modern computation.\n\nIn the SSI space there a number of standards bodies that facilitate SSI-standard development. Though we may utilize specifications in multiple organizations such as the [IETF](https://www.ietf.org/), [OpenID Foundation](https://openid.net/foundation/), the [World Wide Web Consortium (W3C)](https://www.w3.org/), and [Decentralized Identity Foundation (DIF)](https://identity.foundation/). TBD’s focus thus far has been primarily with the W3C and [DIF](http://identity.foundation/) organizations:\n\n### The W3C\n\nThe W3C, founded by [Tim Berners-Lee](https://en.wikipedia.org/wiki/Tim_Berners-Lee) in 1994, is one of the most prominent international standards organizations for the web. The W3C has a number of group types. Community Groups are the most open. The [Credentials Community Group](https://www.w3.org/community/credentials/) focused on Verifiable Credentials, and often serves as a staging ground for the [Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc), responsible for the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model) (i.e. the Verifiable Credentials specification). The [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did) is responsible for [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (i.e. the DID specification).\n\nTBD is a member of the W3C, actively utilizes the work items from all three groups, and has made contributions to each group’s corpus.\n\n### The Decentralized Identity Foundation\n\nThe Decentralized Identity Foundation, or DIF, was founded in 2017 to focus on Decentralized Identity. Since then, it’s expanded to house a number of working groups around Identifiers, Claims & Credentials, Sidetree, Secure Data Storage, Wallet Security, Interoperability, and more. DIF produces technical specifications, reference implementations (as in the case of Sidetree and [ION](https://identity.foundation/ion)), and coordinates standards and software implementations for players across the industry.\n\nTBD is a member of DIF, regularly attends working groups, contributing to both interoperability projects, specifications, and technical implementations.\n\n### Standards in Use\n\nThe set of standards we rely on and use for Web5 is unbound. However, we have a good sense of the standards we begin with. The list below will likely soon be out of date. Consider it as a reference as you orient yourself with what we’re working with.\n\n| Specification | Standards Body | Description | Status |\n| --- | --- | --- | --- |\n| [DID Core](https://www.w3.org/TR/did-core/) | [W3C Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did) | Decentralized Identifiers v1.0. | Recommendation |\n| [DID ION](https://identity.foundation/ion/) | [DIF Sidetree](https://identity.foundation/working-groups/sidetree.html) | A layer 2 Decentralized Identifier network that runs atop the Bitcion blockchain, built on the Sidetree protocol. | Ratified Specification |\n| [DID Key](https://w3c-ccg.github.io/did-method-key/) | [W3C CCG](https://www.w3.org/community/credentials/) | A simple method to create a DID using a single cryptographic key. | Unofficial Draft |\n| [DID Web](https://w3c-ccg.github.io/did-method-web/) | [W3C CCG](https://www.w3.org/community/credentials/) | A DID method that allows bootstrapping trust using a web domain. | W3C Internal Document |\n| [DID Peer](https://identity.foundation/peer-did-method-spec/) | [DIF Identifiers & Discovery](https://identity.foundation/working-groups/identifiers-discovery.html) | A DID method that can be used independent of any central source of truth, intended to be “cheap, fast, scalable, and secure.” | Draft |\n| [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | The Verifiable Credentials Data Model v1.1. | Recommendation |\n| [Data Integrity](https://github.com/w3c/vc-data-integrity) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | Describes mechanisms for ensuring the authenticity and integrity of structured digital documents…such as digital signatures. | Editor’s Draft |\n| [JSON Web Signature 2020](https://w3c.github.io/vc-jws-2020/) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | A cryptographic suite for the purpose of creating and verifying proofs for JSON Web Signatures using Linked Data Proofs. | Editor’s Draft |\n| [Verifiable Credentials JSON Schema](https://w3c-ccg.github.io/vc-json-schemas/v2/index.html) | [W3C CCG](https://www.w3.org/community/credentials/) | A mechanism to use JSON schemas to back a Verifiable Credential.  | Draft |\n| [Status List 2021](https://w3c-ccg.github.io/vc-status-list-2021/) | [W3C CCG](https://www.w3.org/community/credentials/) | A privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials. | Draft Community Group Report |\n| [VC Proof Format Test Suite](https://identity.foundation/JWS-Test-Suite/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A test suite providing interoperability testing and reporting for Verifiable Credentials and Presentation for Linked Data and JWT signature types. | Unofficial Draft |\n| [Presentation Exchange](https://identity.foundation/presentation-exchange/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A claim format and transport envelope agnostic format for Verifiers to articulate proof requirements, and for Holders to describe proofs according to those requirements. | Working Group Draft |\n| [Credential Manifest](https://identity.foundation/credential-manifest/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A common data format for describing the inputs a Subject must provide to an Issuer for evaluation and issuance of credentials, a means for a Subject to submit an application against those requirements, and a means for an Issuer to fulfill such an application. | Pre-Draft |\n| [Trust Establishment](https://identity.foundation/trust-establishment/) | [DIF Claims & Credentials](https://identity.foundation/working-groups/claims-credentials.html) | A means of communicating trust statements and relations between parties in decentralized identity environments. | Pre-Draft |\n| [Decentralized Web Node](https://identity.foundation/decentralized-web-node/spec/) | [DIF Secure Data Storage](https://identity.foundation/working-groups/secure-data-storage.html) | A DWN is a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given DID. DWNs provide multi-node sync, enabling the owning entity to secure, manage, and transact their data with others without centralizing factors. | Draft |\n\nFor brevity, I only included fifteen of the most prominent specifications comprising the foundations of the SSI stack in Web5. There are at least another half dozen either included or planned to be included in our software.\n\n## TBD Community\n\nTBD is interested in building a space for community-driven projects, community members gaining merge and moderation access to community resources, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5. \n\nWe are not interested in becoming a standards body itself. Instead, we are focused on fostering a self-sustaining community focused on building and building on Web5. To facilitate this, we can expand our existing tools like adding sections of our [Forums](https://forums.tbd.website/), creating new [Discord](https://discord.gg/tbd) channels, creating new purpose-specific [GitHub repositories](https://github.com/TBD54566975) and investing in new tools for collaboration like an ideas board, job listing page, or a Web5 wiki. I’d love to see a Web5 incubator similar to [Y Combinator](https://www.ycombinator.com/) that facilitates those building on Web5. The future’s possibilities are endless, and we are eager to adapt to the evolving needs of the community.\n\nSometimes, we may need more rigorous structure. As such, we are interested in forming working groups in the Web5 community where it makes sense. The output of these groups could be industry coordination, use-case building, software development, or even standards-related work that can be contributed to existing standards bodies. TBD has kicked off one such group to date around Credentials, first focused on creating a path for Know Your Customer (KYC) Credentials. This group already follows such a pattern: having built out [use-case documentation in GitHub](https://github.com/TBD54566975/credentials-working-group), having a purpose-specific [Discord channel](https://discord.com/channels/937858703112155166/969682739005624412), and [forum category](https://forums.tbd.website/c/self-sovereign-identity-users/credentials-working-group/6). Soon we’ll adapt this group to a more “office hours”-style format, allowing anyone in the community to show off their work, ask for assistance, and help shape our project development roadmaps. \n\nToday we have one [GitHub org](https://github.com/TBD54566975), run by the TBD team. We will open up roles for community management. Creating light processes for community-driven moderation and maintenance (e.g. managing pull requests, issues, labels, and milestones), in addition to having projects and repositories started and managed entirely by members of the community. One such idea we are considering is for a new GitHub organization for the “Web5 Community” to foster and highlight community-driven efforts. We’re additionally looking to launch an Incubation program that gives a formal path towards recognizing and promoting the work that begins in a grassroots manner in our community. We plan on making the rest of our tooling community-driven as well: today this means Discord and the Forums, tomorrow it will be a lot more!\n\nWhile this is something we are focused on internally, it is crucial that you as community members are able to make suggestions, plans, and directly influence change. Reach out on Discord, our Forums, gain mindshare for your ideas, and we will help make them a reality.\n\n## Open Source\n\nThe foundations of Web5 are [open source](https://github.com/TBD54566975). This means that its source code is publicly available and, as stewards, we rely on external contribution—Web5 is only successful with the full innovation of a global community. Certainly there are cases where code cannot be open source for various reasons: this applies to the TBD business as well as members of our community. We do not mandate open source, but it is a guiding principle. We believe in the power of open, and all that comes with it. The more open Web5 can be, the better it will be.\n\nProjects in the TBD GitHub may originate at TBD, or through the community (on our Discord, Forums). Today, the TBD team is acting as the primary steward and maintainer of all projects. As the community matures, we expect it to take the lead and for TBD to assume a higher-level maintainer role. We imagine this ends up looking like more community-driven projects, community members gaining merge and moderation access, and growing a diverse set of contributors interested in a broad set of use cases to be built on Web5. More broadly, we want to push forward to a world where TBD does not have the only, or final say on any Web5 decision: **decentralization is a strength in the development of Web5**.\n\nThis transition is only made possible by active engagement from the community. It is the reason our code is open, and we have set up avenues for engagement. We look towards the community to engage with TBD and others, and push for the future we wish to see built.\n\n## Software Vision\n\n**TBD is fostering a set of community-driven, open source, standards-based software to facilitate Self Sovereign Identity on Web5.**\n\nWe want to realize the vision of the Web5 community: *to build pragmatic standards-based software that serves a wide variety of needs*. The software shall not be tied to any specific entity, nor, without good reason, exclude possibilities within the SSI space. Balancing both feature-richness and complexity we must work closely with our users to design software that meets the needs of all who wish to be on Web5. We think in terms of toolkits, composed of the purpose-specific tools in them. These toolkits exist in a hierarchy of abstractions from which powerful, intuitive, and human-centric software can be built.\n\nThe software must be designed in a flexible, modular manner. This means interfaces that feature a default implementation or two, but can be extended to facilitate integration into many systems (e.g. swapping out databases, encryption methods, credential formats as needed). The software is intended to be built on open standards in the SSI space. The standards space is fast-changing and there may be cases where we use ill-defined and ill-supported standards; we must be able to favor practicality and working implementations over robust standards with a commitment to see the standards through. There may be cases where we use our software to innovate past the current state of these standards and open the opportunity to contribute back to existing standards and standards bodies.\n\nWe recognize that the SSI ecosystem is full of competing and developing standards. Often this can feel like developing against a set of moving targets and promises of feature sets. There’s a lot of information to grok and everyone has an opinion—this is a good thing! It can be difficult to pick winners, and even more difficult to choose between multiple standards that appear to do the same thing: we do not want to create a Swiss Army knife that contains five different types of scissors, we’d rather it contain one (or maybe two) scissors that get the job done well 99% of the time. We favor evaluating the addition of features and standards on a case-by-case basis, and looking towards implementations of standards and features that are well-reasoned, with committed developers. Bonus points if there is already demonstrated usage and interoperability.\n\nWe also recognize that the SSI ecosystem uses a wide set of tools, languages, and technologies: working across web browsers, mobile applications, backend servers, ledgers, and more. For languages we’ve started with [Go](https://go.dev/) (for the SSI SDK and SSI Service) because of its robust cryptographic support, speed, ability to be compiled to [WASM](https://webassembly.org/), and, above all else, simplicity. It is crucial that the code we write is approachable to encourage contribution. Simple and clear is always preferred over clever. The future is multi-language, and multi-platform. We welcome initiatives for improving multi-language and multi-platform support, and are open to fostering them into our GitHub organization.\n\n## SSI SDK\n\nNamed `ssi-sdk`, this SDK encapsulates a set of standards related to [Self Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html). The `ssi-sdk` intends to provide flexible functionality based on a set of standards-based primitives for building decentralized identity applications in a modular manner: with limited dependencies between components.\n\nPrimarily, the SDK serves to support Decentralized Identifiers and Verifiable Credentials and their associated standards. Interacting with Decentralized Identifiers: resolving identifiers, signing, verifying, encrypting, and decrypting data using cryptographic keys found in DID Documents. Interacting with Verifiable Credentials: creating and using data schemas, facilitating credential application, issuance, and exchange.\n\nThe SDK is an active work in progress, and can be found on the [TBD GitHub](https://github.com/TBD54566975/ssi-sdk).\n\n## SSI Service\n\nThe Self Sovereign Identity Service (SSIS) facilitates all things relating to [DIDs](https://www.w3.org/TR/did-core/) and [Verifiable Credentials](https://www.w3.org/TR/vc-data-model) — in a box! The service is a part of a larger [Decentralized Web Platform](https://developer.tbd.website/projects/web5) architecture. The SSI Service is a JSON-API web service that wraps the [ssi-sdk](https://github.com/TBD54566975/ssi-sdk) to facilitate user-focused interactions on Web5. The service is intended to interact with user interfaces, wallets, decentralized web nodes, and other web infrastructure. \n\nBy taking the lower-level building blocks exposed by the SDK, the service is intended to drastically lower the barrier to entry for any individual or organization interesting in building on the Web5 stack. Like the SDK, it is agnostic to any specific business or use case, and design to be pluggable into external infrastructure whether existing or new. \n\nThe service is assumed to be run by a single organization and assumes external authentication and authorization. The service assumes no infrastructure requirements and is flexible to multiple deployment models, databases, key management solutions, and user interfaces. We expect that a wide array of users and use cases will use and build on top of the service, creating layers of abstraction and intermediation for processing business logic, handling user accounts, and so on.\n\nThe service is an active work in progress, and can be found on the [TBD GitHub](https://github.com/TBD54566975/ssi-service).\n\n## How Features are Developed\n\nWe are in the early days of Web5. By intention, we’ve announced our ideas and projects way before they are ready for an alpha release, let alone inclusion in a production-ready application. Transparency is an asset in sharing our thinking and gaining mindshare for what we are building. As such, there are many forks in the road fast-approaching. To move past these forks, and the forks after those I introduce some light process to guide principled decision making:\n\n1. Features shall be developed using the [Socratic method](https://en.wikipedia.org/wiki/Socratic_method): making statements, interrogating them, asking *whys* and *hows*, being intellectually honest with risk, uncertainty, consider second, third and n-order effects.\n2. All new feature proposals shall include a light design document outlining desired functionality, end-user utility, prior art, room for improvement and next steps, risks and mitigations, considerations, and open questions.\n3. A quorum of project maintainers shall review and progress feature proposals in a timely manner.\n\nTemplates for the aforementioned process have been created on each GitHub repository. I encourage you to create GitHub issues and Forum discussions to explore thinking, and revise designs before going forth with a contribution.\n\nFor templates on feature development, philosophies on versioning and releases, and more information view our GitHub documentation: \n\n[SSI Service GitHub Docs](https://github.com/TBD54566975/ssi-service) | [SSI SDK GitHub Docs](https://github.com/TBD54566975/ssi-sdk)\n\n## The Goal\n\nI believe in setting public and ambitious *measurable* goals. This serves as a powerful self-discipline mechanism, as well as a call to action for forward progress. Officially the [timeline for Web5 can be found on our site](https://developer.tbd.website/blog/web5-roadmap). Unofficially, here is my ambition:\n\n**By January 1st 2023 the following shall be true:**\n\n- The first beta release of the SSI SDK and SSI Service (0.1.0) will be released.\n- Each SSI project will have >75% test coverage.\n- Each project will have robust user and developer documentation with clear examples.\n- The SSI SDK will have feature complete specification implementations for at least all fifteen standards identified above.\n- The SSI Service will be deployable in an infrastructure-agnostic manner, demonstrated on ≥ 2 platforms.\n- The SSI Service will facilitate practical end-user flows facilitating:\n    - Creating and managing DIDs using ≥ 2 DID methods\n    - Creating and issuing Verifiable Credentials backed by JSON schemas\n    - Creating Credential Manifests, accepting Credential Applications, and fulfilling Credential Applications\n    - Creating Presentation Definitions, sending Presentation Requests, and accepting Presentation Submissions\n    - Creating Credential Revocations and checking Credentials against them\n    - Creating and processing Trust Establishment documents\n- The SSI SDK and Service will support the Decentralized Web Node specification and the Service will work with at least one DWN.\n\n## Parting Thoughts\n\nYou should now have a pretty good sense of how we conceive of SSI software on Web5, and how its journey will unfold. Most importantly the mission is not TBD’s alone, it is that of the community. We build real software for real people and favor pragmatism above all else. What I’ve written here is *current thinking* and is always subject to evolution—with your help. I’m looking forward to you joining us in pushing SSI and Web5 forward, gaining new perspectives, solving new use-cases, and building some cool shit."
./.docusaurus/docusaurus-plugin-content-blog/default/blog-archive-80c.json:      "content": "<head>\n  <title>What are Verifiable Credentials?</title>\n  <meta name=\"description\" content=\"What are verifiable credentials, who issues them, and how do they get verified\" />\n  \n  <meta property=\"og:url\" content=\"https://developer.tbd.website/blog/what-are-verifiable-credentials\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:title\" content=\"What are Verifiable Credentials?\" />\n  <meta property=\"og:description\" content=\"What are verifiable credentials, who issues them, and how do they get verified\" />\n  <meta property=\"og:image\" content=\"https://developer.tbd.website/assets/images/what_are_vcs_banner-1ec4bea6c245b62b76685a338d5f8d63.png\" />\n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta property=\"twitter:url\" content=\"https://developer.tbd.website/blog/what-are-verifiable-credentials\" />\n  <meta name=\"twitter:title\" content=\"What are Verifiable Credentials?\" />\n  <meta name=\"twitter:description\" content=\"What are Verifiable Credentials, who issues them, and how do they get verified\" />\n  <meta name=\"twitter:image\" content=\"https://developer.tbd.website/assets/images/what_are_vcs_banner-1ec4bea6c245b62b76685a338d5f8d63.png\" />\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n## \n\n![What Are Verifiable Credentials](/img/what_are_vcs_banner.png)\n\nWhen you hear the term 'credential', what comes to mind? Is it a driver's license, passport,  birth certificate, college degree, state ID? The common thread of these forms of credentials is that they are physical items, verified by recognized centralized bodies like a government agency or accredited university.  \n\nSo how do credentials translate into the digital world where within a few clicks someone can make a fictitious identity? Introducing... **verifiable credentials** (VCs), a digitally signed electronic credential that follows an [open standard](https://www.w3.org/TR/vc-data-model/) that lets you create, own, and manage your credentials across a variety of platforms.\n\n<!--truncate-->\n\n## Why Do We Need Verifiable Credentials?\n\nOver the course of your digital history, you've likely signed up for hundreds of apps and services with elements of your personal data fragmented, such as your name, email address, or more sensitive information like your date of birth and government ID number. These services then share your data with other third parties that you may not even be aware of - with or without your consent. It's difficult to go back and deactivate your profiles, delete your accounts, or reclaim additional data these services have collected on you. Worse is if there is a data breach in one of these services and now your data is out in the public.\n\nVerifiable Credentials aim to solve these problems by putting the power to manage your data back into your hands. Imagine being able to own and control your personal data by only allowing access to services that require it and having the authority to disable services that no longer need it. You can even manage your data on your own self-hosted decentralized web node via an identity hub without relying on any centralized third party. \n\nAdditionally, you can own multiple Verifiable Credentials for various use cases such as a student ID, a driver's license, a passport, or a certificate you earned. You can also have one specific Verifiable Credential with multiple [presentation layers](https://www.w3.org/TR/vc-data-model/#presentations) such as a passport where certain metadata is presented when used in a given context.\n\n## How Do Verifiable Credentials Work?\n\nYou may be wondering who actually issues a Verifiable Credential, how does it get verified and who verifies the verifier? \n\nLet's look at the following example of the manual way credentials are issued. You've been accepted to your top university of choice and now need a student ID to access both the campus and online resources. Specifically, you want to apply for a campus parking permit as well. \n\nTypically this process would involve you taking physical copies of multiple forms of ID verification such as a passport, birth certificate, and driver's license to a physical office. Then after a few days of various checks, you're finally issued a physical student ID card from that university. The university trusts the entity that issued your birth certificate, passport, and driver's license to create a student ID for you. They can even look you up by the identification numbers on these documents. \n\nBut what if someone in the admissions office looked up your driver's license and noticed those parking tickets you have? Were they even allowed to do so and could this bias their decision to give you a parking permit?\n\nThe current process looks something like this:\n\n![Issuing a Student ID manually](/img/issue_student_id_manually.png)\n\n\nNow let’s look at how verifiable credentials could help in this scenario. The university would run verification checks for each document provided (passport, driver’s license, birth certificate, etc) and the credential would be limited to just basic bio data that is required such as a legal name, date of birth, etc. So no one from the student department will be able to see your ticketing history associated with your driver’s license.\n\n![Issuing a Student ID as a Verifiable Credential](/img/issue_vc_for_student_id.png)\n\n\n## Using Verified Credentials \n\nDecentralized identifiers (DIDs) work alongside Verifiable Credentials. DIDs are unique identifiers that let us reference various VCs and the entities that also issue those credentials. For example a government or company can have their own unique DID. \n\n**DIDs use the following schema:**\n\n![did:example:12345abcde](/img/did-format.png) \n*photo credit: W3C*\n\nDIDs can then be used to create a Verified Credential by digitally signing it and assigning it to a holder, similar to how transactions are cryptographically signed in a blockchain. Depending on the signature format of the credential, the holder (also known as a DID subject) can then choose how much of that credential they want to present to an entity requesting the credential, which is referred to as selective disclosure. \n\nAn example is an employer, Company X, who looks up the DID of your college diploma from University Y. \n\nCompany X queries the issuer of your Diploma Verifiable Credential, in this case University Y, and also looks up the DID of that university in a verifiable data registry (VDR). Think of VDRs as just lists that can be managed and maintained by various parties such as wallets, financial institutions, DAOs, non-profits, etc. If your credentials have valid digital signatures but somehow University Y is on a list of non-accredited institutions in the USA but accredited institutions in Europe, it would be up to the Company X to decide if they want to accept it.\n\nThe diagram below outlines the flow of this process.\n\n![issuer issues a verifiable credential to a holder who can send a presentation of their VC to a verifier](/img/vc_ecosystem.svg)\n*photo credit: W3C*\n\n\n## Use Cases for Verifiable Credentials\n\nThere are several use cases that can be realized with the use of Verifiable Credentials, such as\n\n- Employment checks without being invasive \n- Managing of health records, land titles, etc\n- Managing of various forms of personal identification such as passports, driver’s licenses, etc \n- KYC (Know Your Customer) checks for financial institutions and businesses\n- Managing your gamer profile across different metaverses\n- Managing Memberships\n\nDIDs and VCs allow us to create identities and credentials in an interoperable ecosystem that allow developers and businesses to build a new wave of products, applications, and services that put users in control."
./.docusaurus/docusaurus-plugin-content-blog/default/blog-archive-80c.json:      "content": "<head>\n  <meta property=\"og:title\" content=\"What is Web5?\" />\n  <meta property=\"og:type\" content=\"website\" />\n  <meta property=\"og:url\" content='https://developer.tbd.website/blog/2022-07-01-what-is-web5' />\n  <meta name=\"og:description\" content=\"Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\" />\n  <meta property=\"og:image\" content=\"/img/what_is_web5.png\" /> \n\n  <meta name=\"twitter:card\" content=\"summary_large_image\" />\n  <meta property=\"twitter:domain\" content=\"developer.tbd.website\" />\n  <meta name=\"twitter:site\" content=\"@tbddev\" />\n  <meta name=\"twitter:title\" content=\"What is Web5\" />\n  <meta property=\"twitter:url\" content='https://developer.tbd.website/blog/2022-07-01-what-is-web5' /> \n  <meta name=\"twitter:description\" content=\"Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\" />\n  <meta name=\"twitter:image\" content=\"/img/what_is_web5.png\" />\n\n  <link rel=\"apple-touch-icon\" href=\"https://developer.tbd.website/img/tbd-fav-icon-main.png\" />\n</head>\n\n![What is Web5?](/img/what_is_web5.png)\n\nWeb 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.\n\nIn the current web model, users do not own their data or identity. They are given accounts by companies and their data is held captive in app silos. To create a new class of decentralized apps and protocols that put individuals at the center, we must empower them with self-owned identity and restore control over their data.\n\n<!--truncate-->\n\nThis platform embraces the convenience of Web 2 but it also returns control back to the users, an ethos of Web 3. The harmony of these two views is what we're calling Web 5.\n\n![{Web 2}{Web 3} -> {Web 5}](/img/web5-graphic.png)\n\n## Components of Web 5\n\nThere are three main pillars of the decentralized web platform, all of which are based on open standards.\n\n![The pillars of Web5 are Decentralized Identifiers (self-owned identifiers that enable decentralized identity authentication and routing), Verifiable Credentials (data formats and models for cryptographic presentation and verification of claims), and Decentralized Web Nodes (data storage and message relay nodes that serve as the foundation for decentralized apps and protocols).](/img/pillars-of-web5.png)\n\n## Decentralized Identifiers\n\nThe identifiers we know and use today are owned by the government, a company, an organization, or some other intermediary. For example, our email addresses and social media handles are identifiers associated with us but are owned and controlled by the service providers. These companies have the right to ban, disable, or delete these identifiers and we have little to no control over this.\n\nSo before we can realize truly decentralized applications, we need decentralized identifiers that users own and control. This removes the dependency on centralized entities to authenticate and represent us.\n\n[Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DIDs) are a W3C standard. They have a standardized structure that essentially links to you and your information.\n\n![A DID is comprised of three parts: Scheme, DID Method, and DID Method Specific String](/img/did-example.png)\n\nThey are a long string of text that consists of three parts:\n\n- the URI scheme identifier, which is did\n- the identifier for a [DID method](https://www.w3.org/TR/did-core/#dfn-did-methods)\n- the DID method-specific identifier\n\nStoring DIDs on [ION](https://identity.foundation/ion/) (a Layer 2 DID network that runs on top of Bitcoin) is a preferred design decision for the implementation of Web 5. ION is a decentralized replacement for DNS for identity identifiers, so there are no authorities, coordinators, tokens, or other centralized bottleneck.\n\n**DIDs are the only component of Web5 that touch a blockchain**, which is generally limited to anchoring the keys/endpoints linked to the ID.\n\nThat being said, anchoring DIDs on Bitcoin (or any blockchain) is not a requirement. In fact, what's great about having the standardized formatting for DIDs is that they can be anchored anywhere or not anchored at all and this still works, although with varying levels of decentralization.\n\nHere are examples of DIDs on the Bitcoin blockchain, the Ethereum blockchain, and the web. Notice they all use the same format: scheme, DID method, and DID method-specific identifier.\n\n```json\ndid:btcr:xyv2-xzpq-q9wa-p7t\ndid:ens:some.eth\ndid:web:example.com\n```\n\nBecause personal data is not stored on the blockchain, the DID essentially acts as a URI that associates the subject of the DID (the person, company, or object being identified) with a DID document that lives off-chain.\n\nDID Documents are JSON files stored in decentralized storage systems such as IPFS, and describe how to interact with the DID subject. The DID Document contains things like the DID subject's public keys, authentication and verification methods, and service endpoints that reference the locations of the subject’s data.\n\n```json\n{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\",\n  \"verificationMethod\": [\n    {\n      \"id\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\",\n      \"type\": \"Secp256k1VerificationKey2018\",\n      \"controller\": \"did:ion:EiClkZMDxPKqC9c-umQfTkR8\"\n    }\n  ],\n  \"authentication\": [\"did:ion:EiClkZMDxPKqC9c-umQfTkR8\"]\n}\n```\n\n## Verifiable Credentials\n\n[Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) are a fully ratified W3C standard that work hand in hand with Decentralized Identifiers to enable trustless interactions - meaning two parties do not need to trust one another to engage, but claims made about a DID subject can be verified.\n\nFor example, Alice needs to prove she has a bank account at Acme Bank. Acme Bank issues a cryptographically signed Verifiable Credential which would be stored in Alice's identity wallet.\n\n![Illustration of Acme Bank issuing a verifiable credential to Alice’s wallet, and the wallet presenting the credential as proof of a bank account to a PFI Verifier.](/img/acme-bank-example.png)\n\nThe credential contains the issuer as Acme and the subject as Alice, as well as the claims, which are Alice's account number and full name.\n\nUpon request for proof of banking, Alice presents the Verifiable Credential that's cryptographically signed by both Alice as well as her bank.\n\nThis is an easy, machine-readable way to share credentials across the web. The Verifier does not know or trust Alice, but they do consider Acme trustworthy, and they have essentially vouched for Alice therefore distributing trust.\n\n## Decentralized Web Nodes\n\nToday, centralized entities act as our data stores. Applications hold all of our content and preferences on their servers.\n\n[Decentralized Web Nodes](https://identity.foundation/decentralized-web-node/spec/) (DWNs) change this by allowing us to decouple our data from the applications that we use, and instead host our data ourselves in our own personal data stores.\n\n[BlueSky](https://blueskyweb.xyz/) is a good example; it's a decentralized version of Twitter that's in the works. With BlueSky, your tweets and your connections aren't stored with the application. They are stored with you. So you can present your content on any decentralized social media app you want, not just BlueSky.\n\nYour DWNs can hold both public and encrypted data. For example, in the case of a decentralized version of Twitter, you'd want data like your tweets and your connections to be public but things like your DMs to be private.\n\n**Your decentralized web nodes do not live on the blockchain**. You can host your web nodes anywhere (your phone, computer, etc) and can replicate them across your devices and clouds and all data will be synced.\n\n![Decentralized Web Nodes is an emerging standard for data storage and relay that enables entities of any type (people, organizations, etc) to send and store encrypted or public messages and data, enabling a wide variety of decentralized apps and protocols to be built on top. Features of Decentralized Web Nodes include: universally addressable, replicated, secure, semantic discovery, async message threads, supports any identity type.](/img/features-graphic.png)\n\nWhile self-hosting your DWNs provides a means for decentralizing your data, we recognize some users will be more comfortable with others hosting their web nodes for convenience sake. We envision there will be vendors offering to host your web nodes for you. The good part about that is you can encrypt any private data so unlike today where cloud hosts can scan everything that you host there, you can still maintain some privacy even if you have your web nodes hosted by intermediaries.\n\nYour DWNs are associated with your Decentralized Identifiers and are listed in a DID document.\n\nNotice the `serviceEndpoint` section of the DID doc specifies service endpoints and provides URIs to the decentralized web nodes.\n\n```json\n{\n  \"@context\": \"https://www.w3.org/ns/did/v1\",\n  \"id\": \"did:web:example.com:u:alice\",\n  \"service\": [\n    {\n      \"id\": \"#dwn\",\n      \"type\": \"DecentralizedWebNode\",\n      //highlight-start\n      \"serviceEndpoint\": {\n        \"nodes\": [\"https://dwn.example.com\", \"00:11:22:33:FF:EE\"]\n      }\n      //highlight-end\n    }\n  ],\n  \"verificationMethod\": [\n    {\n      \"id\": \"did:web:example.com:u:alice\",\n      \"type\": \"Secp256k1VerificationKey2018\",\n      \"controller\": \"did:web:example.com:u:alice\"\n    }\n  ],\n  \"authentication\": [\"did:web:example.com:u:alice\"]\n}\n```\n\nGiven an application has the address to your DWN, they can send you a request for data.\n\nThis represents a request from an application to obtain all objects within a DWN that follow the `SocialMediaPosting` schema:\n\n```json\n    POST https://dwn.example.com/\n    BODY {\n      \"requestId\": \"c5784162-84af-4aab-aff5-f1f8438dfc3d\",\n      \"target\": \"did:example:123\",\n      \"messages\": [\n        {\n          \"descriptor\": {\n            \"method\": \"CollectionsQuery\",\n            \"schema\": \"https://schema.org/SocialMediaPosting\"\n          }\n        },\n        {...}\n      ]\n    }\n```\n\nThe data within DWNs are JSON objects that follow a universal standard, thus making it possible for any application to discover and process the data given its semantic type.\n\nIf this data is public, those objects will be automatically returned to the application, and if the data is private, the node owner would need to grant the application access to that data.\n\n## Identity Wallets\n\nObviously all of this is pretty complicated, especially for non-technical users. So we need a simplistic, easy to use interface that will allow people to access and manage their identity.\n\nA well designed identity wallet would provide ways to manage the data stored in decentralized web nodes, the decentralized IDs and the context in which they should be used, verifiable credentials, and authorizations.\n\n![Identity wallets are mobile apps that provide UI and functionality to manage credentials and app data stored in Decentralized Web Nodes; sign, verify, discover, and present credentials to verifying parties; perform authentication and manage authorizations; support create, update, and recovery of DIDs across all supported DID Methods; maintain and enforce which DIDs are used with different people, apps, and services.](/img/identity-wallets.png)\n\n## Decentralized Web Apps\n\nWeb 5 enables developers to build decentralized web applications (DWAs) on top of it and it’s all open source! You're free to use it as your foundation and focus your attention on what you really care about, your app. Web5 brings to DWAs what cloud and application servers bring to enterprise apps. It does the hard part. It brings decentralization. By building your apps on top of Web 5, you get decentralization and identity and data management as part of the platform.\n\nThis is definitely a fundamental change in how we exchange data, but it's not a total overhaul of the web we already know. This works like Progressive Web Apps, but you'd add the decentralized web node SDK and then applications are free to really go serverless because the data isn't stored with them.\n\n![Illustration of PWAs compared to DWAs. PWAs comprise of a web app that uses a service worker to pull from local cache and a centralized app server; whereas DWAs comprise of a DWN SDK and a service worker that pull from local cache and Decentralized Web Nodes.](/img/pwa-dwa.png)\n\nThe sky's the limit to what you can build on top of this platform, but here are some cool basic examples.\n\n## Music Applications\n\nNo one likes recreating their music playlists over and over again for different apps. With Web 5, you wouldn't have to do that.\n\nIn this example, Groove has access to write to Alice's decentralized web node and adds a new entry.\n\nTidal has access to read from Alice's DWN, so can read the new entry that was added by Groove, and now Alice has her playlist readily available on both apps.\n\n![Illustration of Groove writing a new schema.org/MusicPlaylist object to Alice’s remote DWN and Tidal, who has read ability, reading the MusicPlaylist entry that Groove added.](/img/music-to-my-ears.png)\n\nWith the continuous utilization of the data across apps, not only do Groove and Tidal get access to Alice's data, but they use it to improve her user experience, thus creating a stronger experience than Alice could have ever gotten had she not used this tech.\n\n## Travel Applications\n\nYour travel preferences, tickets, and reservations are scattered across so many different hotels, airlines, rental car agencies and travel apps, making it really difficult to coordinate. Heaven forbid there's any hiccup in the system such as a delayed flight. You end up trying to get in touch with the car rental place to let them know you'll be late for your reservation, and if it's really late, you'd want to call the hotel to ask them not to give away your room. All while you're hustling and bustling at the airport.\n\nWeb 5 can help unify these various app experiences.\n\nIf Alice gives the hotel, the airline, and the rental car agency access to the `Reservation` and `Trip` objects in her DWN, they can react and adjust accordingly to any changes made.\n\n![Illustration: Alice grants her hotel, airline, and rental car provider the ability to add schema.org/Reservation objects to her collection of trip-related data and also grants any app she chooses access to reservations and tickets stored in her schema.org/Trip data to help her visualize her itinerary.](/img/hotel-travel-plans.png)\n\nThese are just a few applications that can be realized by building on top of Web 5. There's so many more possibilities once the web is truly decentralized the way it was always intended to be.\n\n## How to Get Involved\n\nWhile we’re super excited about this technology, there's still lots of problems to be solved. We welcome you to join us in making the web we all deserve.\n\n- Check out our [GitHub projects](https://github.com/TBD54566975/collaboration/blob/main/projects/GETTING_STARTED_DWP.md), if you’d like to see more or contribute to the components.\n\n- We have [open job reqs](https://www.tbd.website/careers) if you’re interested in formally working on decentralized technologies.\n\n- If you're a company who is trying to solve these same challenges or could make use of any of these components, [we'd love to collaborate](https://www.tbd.website/connect).\n\n- If you’d like to join the community, we’re on [Discord](https://discord.gg/tbd)."
./blog/2022-08-17-what-are-verifiable-credentials.md:DIDs can then be used to create a Verified Credential by digitally signing it and assigning it to a holder, similar to how transactions are cryptographically signed in a blockchain. Depending on the signature format of the credential, the holder (also known as a DID subject) can then choose how much of that credential they want to present to an entity requesting the credential, which is referred to as selective disclosure. 
./blog/2022-08-26-ssi-tbd-web5.md:| [DID Key](https://w3c-ccg.github.io/did-method-key/) | [W3C CCG](https://www.w3.org/community/credentials/) | A simple method to create a DID using a single cryptographic key. | Unofficial Draft |
./blog/2022-08-26-ssi-tbd-web5.md:| [JSON Web Signature 2020](https://w3c.github.io/vc-jws-2020/) | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) | A cryptographic suite for the purpose of creating and verifying proofs for JSON Web Signatures using Linked Data Proofs. | Editor’s Draft |
./blog/2022-08-26-ssi-tbd-web5.md:We also recognize that the SSI ecosystem uses a wide set of tools, languages, and technologies: working across web browsers, mobile applications, backend servers, ledgers, and more. For languages we’ve started with [Go](https://go.dev/) (for the SSI SDK and SSI Service) because of its robust cryptographic support, speed, ability to be compiled to [WASM](https://webassembly.org/), and, above all else, simplicity. It is crucial that the code we write is approachable to encourage contribution. Simple and clear is always preferred over clever. The future is multi-language, and multi-platform. We welcome initiatives for improving multi-language and multi-platform support, and are open to fostering them into our GitHub organization.
./blog/2022-08-26-ssi-tbd-web5.md:Primarily, the SDK serves to support Decentralized Identifiers and Verifiable Credentials and their associated standards. Interacting with Decentralized Identifiers: resolving identifiers, signing, verifying, encrypting, and decrypting data using cryptographic keys found in DID Documents. Interacting with Verifiable Credentials: creating and using data schemas, facilitating credential application, issuance, and exchange.
./blog/2022-07-01-what-is-web5.md:![The pillars of Web5 are Decentralized Identifiers (self-owned identifiers that enable decentralized identity authentication and routing), Verifiable Credentials (data formats and models for cryptographic presentation and verification of claims), and Decentralized Web Nodes (data storage and message relay nodes that serve as the foundation for decentralized apps and protocols).](/img/pillars-of-web5.png)
./blog/2022-07-01-what-is-web5.md:For example, Alice needs to prove she has a bank account at Acme Bank. Acme Bank issues a cryptographically signed Verifiable Credential which would be stored in Alice's identity wallet.
./blog/2022-07-01-what-is-web5.md:Upon request for proof of banking, Alice presents the Verifiable Credential that's cryptographically signed by both Alice as well as her bank.
./blog/2022-09-28-tbd-circle-partnership.md:* Ubiquitous global on-and-off-ramps that connect traditional payments rails to digital assets, making it easier and more accessible for consumers and businesses around the world to benefit from the crypto economy.
./blog/2022-09-28-tbd-circle-partnership.md:This partnership aims to make a significant impact on peoples’ everyday financial lives. It both fuels the potential for crypto to emerge as a mainstream payments system while establishing decentralized identity as the model for building trust in a scalable and privacy-preserving way.
./blog/2023-01-10-ssi-chat-gpt.md:This can have a few advantages but the interesting thing for us is that this can allow sharing of implementations of functionality: credential issuance, DID resolving, cryptographic functions, etc which you may not want to necessarily re-implement in JavaScript or TypeScript.
./package-lock.json:    "node_modules/crypto-random-string": {
./package-lock.json:      "resolved": "https://registry.npmjs.org/crypto-random-string/-/crypto-random-string-2.0.0.tgz",
./package-lock.json:        "crypto-random-string": "^2.0.0"
./package-lock.json:    "crypto-random-string": {
./package-lock.json:      "resolved": "https://registry.npmjs.org/crypto-random-string/-/crypto-random-string-2.0.0.tgz",
./package-lock.json:        "crypto-random-string": "^2.0.0"
Binary file ./.git/index matches
./src/content/projects/tbdex/data-self-ownership.mdx:access his transactions, cryptocurrency balances, and dark mode preference from his
./src/content/projects/tbdex/proving-your-identity.mdx:USD in exchange for 100 units of cryptocurrency. Because Alice is <TooltipWrapper trigger="off-ramping">
./src/content/projects/tbdex/proving-your-identity.mdx:</TooltipWrapper> from cryptocurrency to fiat, most Participating Financial Institutions
./src/content/projects/tbdex/proving-your-identity.mdx:</TooltipWrapper> issued from the past PFI to the bidding PFI, along with the cryptocurrency
./src/pages/projects/ssi-sdk/README.md:- [Linked Data Cryptographic Suite Registry](https://w3c-ccg.github.io/ld-cryptosuite-registry/) _Draft Community Group
./src/pages/projects/ssi-sdk/README.md:// Outputs an .xcframework for the crypto, cryptosuite, did packages
./src/pages/projects/ssi-sdk/README.md:// Outputs a .jar and .aar for the crypto, cryptosuite, did packages
TBD54566975 / developer.tbd.website

Remove references to "cryptocurrency" in favor of "Bitcoin" or "digital money" #356
