AKASHA joins the World Wide Web Consortium

We are very excited to announce that starting April 1st, AKASHA has officially joined the World Wide Web Consortium! 🙌

While W3C is mostly about the Web, a lot of the work that takes place here is about more than just the Web. You'll notice that within this comprehensive list of all the current Working Groups, there are some that are dedicated to security, privacy, accessibility, and even education. If you think about it, not a day goes by without us interacting in some way with the Web, or at least with a browser.

What is World Wide Web Consortium?

There are many reasons why standards are important when creating new technology. Historically, Web standards were introduced to protect the Web ecosystem, to keep it open, free and accessible to all. Putting the Web in a protective bubble and disbanding with the idea of having to build websites to suit specific browsers. The resultant cross-compatibility (interoperability) made things a lot easier for content makers, avoiding their having to build multiple versions of the same website. Please remember that the main reason we have an open Web today is primarily due to W3C's patent policy that makes sure W3C Recommendations can be implemented on a Royalty-Free (RF) basis. Without it, the Web would be a completely different place today.

Standards are also important because they ease the path of adoption by developers, by reducing development and maintenance time. Software built on standards is often used in many projects, while at the same time being more robust, since developers from different companies often contribute to one codebase (catching bugs, adding tests, etc.). On the same note, we are guaranteed to always have better standards when different companies and individuals (W3C Invited Experts) pool their resources together, bringing to the table different use cases coming from all sorts of backgrounds, instead of a single company working on it.

The reason why the AKASHA Foundation joined the W3C is to participate in two Working Groups, the Verifiable Claims WG, and an upcoming Decentralized Identifiers WG, which is currently incubated by the Credentials Community Group. Let's take a closer look at what each of these groups are producing.

Verifiable Claims

Entities (people, organizations, devices) need to make many kinds of claims as part of their everyday activities. As more and more of these important activities move to the Internet, entities need to be able to transmit instantly verifiable claims (e.g. about their location, accomplishments, value, etc). From educational records to payment-account access, the next generation of Web applications will authorize entities to perform actions based on rich sets of credentials issued by trusted parties. Human- and machine-mediated decisions about job applications, account access, collaboration, and professional development will depend on filtering and analyzing growing amounts of data. It is essential that data be verifiable.

A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate presentations and then share these presentations with verifiers to prove they possess verifiable credentials with certain characteristics.

It is also possible for claims to be issued by individuals in order to self-certify certain pieces of data, in a way that makes the claim issuer and the claim holder the same entity. For example, the AKASHA dapp could use claims to allow authors to prove ownership of posts and comments.

What is interesting is that Verifiable Claims make use of Decentralized Identifiers (DIDs) when mentioning different entities as well as signature keys.

If you would like to know more about how Verifiable Claims work, please take a look at the Proposed Recommendation document, which is in the last stage before officially becoming a W3C Recommendation.

Decentralized Identifiers

Today’s Internet places control of online identities into the hands of third-parties. Email addresses, usernames, and website domains are borrowed or "rented" through DNS, X.509 certificates (TLS), and social networks. This results in severe usability and security challenges Internet-wide, both for regular users as well as service providers.

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID.

In other words, DIDs offer a new way to express identifiers that are not bound exclusively to the Web and centralized service providers, yet they remain compatible with many general-purpose Web technologies. They are also not limited to a single use case or protocol, since a Decentralized Identifier is nothing more than a generic Uniform Resource Identifier (URI) -- for example did:example:123456789abcdefghi -- which is unique at the scale of the Internet, and that points to a document containing several attributes defining a person, an object, or organization. Please note that it is up to each individual to decide how much information they want to expose in a DID document, by adding or omitting certain attributes from the document.

The following is a basic example of a self-managed DID Document. JavaScript { "@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "authentication": [{ // this key can be used to authenticate as did:...fghi "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "service": [{ "type": "ExampleService", "serviceEndpoint": "https://example.com/endpoint/8377464" }] }

The emergence of blockchain technology provides the opportunity to implement fully-decentralized identity management (DIDM). In DIDM, all identity owners share a common root of trust in the form of a globally-distributed ledger. Each DID record is cryptographically secured by private keys under the identity owner’s control. One of the many benefits it offers is that DIDs are designed to work with different blockchains and other target systems, therefore providing interoperability.

DIDs can also be used for authentication, where similarly to other authentication methods, DID Auth includes the ability to establish mutually-authenticated communication channels and to authenticate to Web sites and applications. During this cycle, an identity owner demonstrates control of their authentication material that was generated and distributed during DID Record Creation through execution of the authentication-proof mechanism. Even though DID Auth is about proving control of a DID, the exchange of Verifiable Credentials associated with a DID is paramount to making DID Auth work, hence the overlap between the two Working Groups.

For regular users, it means that you would typically have a digital wallet that stores your DIDs and associated keys, and you could use a browser plugin or app that pops up and asks for confirmation when you are logging in. The idea is a bit comparable to the MetaMask plugin, but less complicated.

How does it all fit with AKASHA's mission?

Whether it is the AKASHA dapp or another project developed under the AKASHA Foundation umbrella, we believe both Working Groups have the potential to further advance self-sovereign technology. Both Verifiable Claims and DIDs are key components that will see reuse throughout numerous use cases, pretty much anything that touches on identity and authentication, to proof of ownership and authorship. Participating in the standards making process keeps the scope of this work very generic, enabling AKASHA to avoid getting tunnel vision when looking for technical solutions in these areas.

More concrete (and short-term), we would like the users of our dapp to be able to reuse their self-sovereign identities (DIDs), whichever identity provider they might be using. This brings numerous advantages, for both users and ourselves as AKASHA, since it means that we will no longer have to maintain user profiles ourselves, as well as all the features and complexity that come with it. Combining Verifiable Claims and DIDs (and perhaps also using Hyperdata), we could potentially enable users to manage content independently of our infrastructure, in a truly decentralized way. We're barely scratching the surface in terms of useful functionality we can add to our platform.

As always, we welcome comments / feedback on our Discord server!