SPEC NO LONGER MAINTAINED HERE Moved to https://gl1.dcdpr.com/btcr 1. Introduction did:btc1 is the secure, reliable bitcoin DID method. It uses bitcoin as a Verifiable Data Registry to store canonical status for a new type of DID. did:btc1 is designed to be secure, flexible and resilient. It supports offline creation, aggregate and singleton DID updates, all without late publishing and without requiring public disclosure of DID documents. Offline creation allows creating DIDs without interacting with the bitcoin blockchain. Aggregated updates allow an arbitrary number of DID document updates to be combined by any agregator and posted to Bitcoin in a single transaction. Directed updates means that resolving parties need only process transactions likely to contain updates for those DIDs of intereset.

Atala Questions We have legacy DIDs that only contain a single MASTER_KEY. Should we translate the master key type to an AUTHENTICATION verification relationship? I am not fully clear what is being asked here. Can these legacy DIDs not be updated to contain more than one key? Also, MASTER_KEY is not a verification relationship in the W3C DID spec so the resolver will need to specify rules against which a key with KeyUsage defined as MASTER_KEY is mapped to a W3C verification relationship (or multiple). If MASTER_KEY the only key defined, then should make that key map to ALL verification relationships. Otherwise DID method unusable for significant portion of use cases. We only allow one verification relationship per key id, do we want to make this more flexible? You could, although one thing to consider is the NIST guidelines recommending a key is only used for a single purpose.

TLDR: if you are going to read one thing then read this about the general Trust over IP stack Hyperledger Aries is an open source project and specification for developing software agents that can communicate across secure cryptographic channels. They can communicate any messages using a protocol called DIDComm, however they are specifically designed to issue and present Verifiable Credentials based on anonymous credential cryptography. The specification is being implemented in numerous coding languages; python, ruby, golang and dotnet to name a few. The idea being that you can develop a aries agent in a language of your choice and be able to interact with any other agent that follows the aries rfcs. There is an interoperability profile which defines which rfcs should be implemented to which version. I have the most experience with the python code base which has largely been developed by the government of british columbia who have been doing great things with this tech. This video gives great deep dive of the architecture of aries agents. An easy way to get started with a fully functioning hyperledger aries agent, controller and user interface can be found in this repo. If you check out the demo-finish branch you can spin up a full ecosystem, with 3 agents alice, faber and acme using docker. The UI's for the agent exists at localhost:4200-4202. If you look at the docker-compose.yml file, it should give you a good idea of the setup. The current UI used can be found in this repo and is written in angular. I have been working to replicate something similar in React, this can be found here. It is not feature complete yet! If you simply swap this repo url with the context for any of alice-web, faber-web or acme-web in the docker-compose.yml of the controller repo you will spin up an agent with the react UI. You can actually pull the project down locally, point to the folder rather than the repo url then edits to the UI will be updated while running the whole system.

This is a quick(ish) explainer and how-to guide for including images inside a Verifiable Credential attribute in such a way that a Verifier can load the image and verify it is the same as the image attested to by the issuer. The problem with an image and probably most files is that their size is greater than a credential attribute was designed to store. Meaning the simple solution to base64 encode the image and include the encoding in a credential attribute will not work. There are two alternative approaches that I have come across previously for implementing this. Perhaps the ideal solution, that will be used in the future involves a Hyperledger Aries concept called a decorator. They provide a way to convey metadata associated with certain communication patterns, I am told it is possible to use decorators to send file attachments over DIDComm. Indeed the RFC shows that aries-cloudagent-python codebase has implemented this. I am yet to explore this for myself, so do not know much more than that. I imagine works by attaching a file to a verifiable credential presentation that includes the hash of that file as one of the attributes. This solution is Self-Sovereign and decentralised. Assuming an issuer has seen the file, created a hash of it and issued it as an attribute of a Verifiable credential. The holder simply needs to prove this file hash attribute along with the file, which they can store wherever they choose, to whoever they wish to prove this verifiable file to. However, the reality today is that this solution is immature and infeasible for most projects despite them still requiring images to be included within credentials in their system. After all, an image is a biometric we as humans are all used to verifying against the holders face. We trust it. We have much less understanding, and hence trust, in the underlying cryptography that allows the verification of attribute integrity and it's authenticated origin. Even if we do place trust in the cryptography, an image is a great way to link a physical human with the digital identifier they are using the represent themselves. The viable solution today is similar to the ideal solution but compromises on decentralisation. Rather than images being passed by the holder along with proof the hash of that image was issued to them, the images are hosted in a central location and holders prove both the URL location and hash of the image within a credential presentation. The verifier can then use the URL to pull down the image, hash it and compare the hash with the hash presented. The problem with this solution, other than the compromise, is the complexity involved when implementing it. There are a lot of decisions to be made about the architecture and associated infrastructure. Let's have a look.

This aims to be a collection of resources, mainly aries rfcs, that will help provide a technical understanding of the OpenMined identity and security roadmap. Hyperledger Aries is an open source project, that forms part of a technology stack for implementing what is often termed Self-Sovereign Identity. The Trust over IP stack rfc is a great place to start - https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack. Establishing a DID Comm communication channel DIDComm is a protocol for sending communication between agents across a channel established first by exchanging decentralised identifiers (DIDs) through a DIDexchange protocol. These identifiers are called peer DIDs, due to the fact that they are created and managed within the context of the peer-to-peer relationship. No one else needs to be involved. DID based communication is designed to be transport agnostic - while currently most implementations use http - the idea is that you can communicate using DIDs across any transport protocol. DIDComm involved Agents - https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents