W3C home > Mailing lists > Public > public-credentials@w3.org > July 2017

Re: Initial insights on DID spec based on this week’s DID:BTCR Hackathon

From: Christopher Allen <ChristopherA@blockstream.com>
Date: Tue, 18 Jul 2017 00:38:13 -0700
Message-ID: <CA+HTxFe284_n-jR2YvLF4dC1SyJnQDo3JzE4=C07KVTdeYmJ-Q@mail.gmail.com>
To: W3C Credentials CG Public List <public-credentials@w3.org>
Cc: Federico Squartini <federico@spidchain.com>, Kim Hamilton <kimdhamilton@gmail.com>
I asked other participants in last week’s DID:BCR hackathon to write up
their thoughts about the results of the hackathon. Here are two responses
so far:

— Christopher Allen


Forwarded conversation
Subject: BTCR hackathon feedback
------------------------

From: Federico Squartini <federico@spidchain.com>
Date: Mon, Jul 17, 2017 at 12:24 PM
To: Christopher Allen <ChristopherA@blockstream.com>


I and Nicola Squartini took part to the BTCR remote hackathon. At Spidchain
we want to provide services built on top of self sovereign identity, and we
are following the development of the specification closely and when
possible we are trying to contribute to it.

This hackathon has seen several interesting advancements, in particular the
insight of Christopher that the DDO can be split in a blockchain stored
"deterministic" part and an "extension" part which can be stored elsewhere,
like github or IPFS. For a production app, probably IPFS is the best choice
although the immutable link between the address and the content could
create some problems.

Another useful insight is that in the BTCR scheme all verifiable claims
must be signed not only by the issuer, but also by the subject to which
they refer to. Only then are they considered verifiable by the protocol.
This in the spirit of self sovereignity, and also because positive
reputation systems are simpler to describe at this stage.

Also it has been decided that the bech32 encoded txref is the standard for
a BTCR DID.

During the hackathon we published
<https://github.com/SpidChain/spidchain-btcr> our (very) early stage BTCR
app. We plan to do the following updates in the next weeks:

 * Implement an SPV wallet in the browser
 * Switch to bech32 DID
 * Use the deterministic DDO with the extended part in IPFS

Discussing with the participants we also came to the conclusion that some
technical limitations like the difficulty of following DDO rotations up to
the unspent tip, can for the moment be sidestepped by using multiple (for
security) external block explorers.

We will report on the hackathon at the next Blockchain Milano meetup.

The remote hackathon has been a great opportunity for everyone interested
in the subject of self sovereign identity an we look forward to the next
one.


Federico Squartini


----------
From: Kim Hamilton <kimdhamilton@gmail.com>
Date: Mon, Jul 17, 2017 at 1:29 PM
To: Christopher Allen <ChristopherA@blockstream.com>, Ryan Grant <
bitcoin@rgrant.org>


Here is mine:

I participated in the BTCR Hackathon during my off hours on behalf of
Learning Machine and Blockcerts. We are committed to user-owned and
-managed credentials, and are keen to integrate DID options into the open
source and commercial products.

One thing I've wanted to see is a minimum viable DID implementation, and
the BTCR method was the best match in my opinion. BTCR relies exclusively
on the Bitcoin blockchain (no vendor-specific services or libraries) and
BTCR DIDs can be created/managed entirely by end users. For this reason, I
see the BTCR DID method as critical in proving out the value and principles
of DIDs.

One benefit of the BTCR Hackathon is that -- as a simple approach -- it
helped improve my understanding of the core DID/DDO concepts. I think this
was true for many participants, and will help our ability to communite
about DIDs more effectively.

My main goal for the hackathon was to communicate the concepts through
(hopefully!) simple code. I wanted to develop user-friendly
libraries/tools, using exclusively blockchain APIs as opposed to requiring
a bitcoind node. While this approach is not a BTCR best practice, I found
it's a useful way for people to understand the mechanics and easily
experiment -- safely in testnet mode to start.

To that end, I created 3 tools:

- BTCR playground. This is still in progress, but can be helpful for
understanding the elements of BTCR DIDs (txrefs, deterministic DDOs, etc)
    - Site: https://weboftrustinfo.github.io/btcr-tx-playground.github.io/
    - Source code: https://github.com/WebOfTrustInfo/btcr-tx-
playground.github.io
- Js library to convert between txrefs and txids, used by the playground
    - https://github.com/WebOfTrustInfo/txref-conversion-js
- Command-line tool (or js library) for generating BTCR DIDs
    - https://github.com/WebOfTrustInfo/btcr-did-tools-js

We struggled a bit with testnet txref encodings (as they were still being
tweaked when we started), but it was fun to get insight into the TxRef BIP
(using Bech32 encoding) during the development stage.

The biggest insight of the hackathon IMO was that of a deterministic DDO
for BTCR, which Christopher has already mentioned. One of our biggest
follow up items will be to bring this learning into the DID spec
discussions.

Another important follow-up item will be some Verifiable Claims
schema-related questions that we ran into while developing samples. All
items are tracked in github issues, and we're in the process of moving
issues to the right repos. We will have lots of fun follow-up at RWoT in
fall!

If you want to see my testnet deterministic DDO, check it out on the
playground:
Playground link: https://weboftrustinfo.github.io/btcr-tx-playground.github.
io/
My testnet Transaction ID: ee112be4810484621cff410051c02a
c1d81b65f1b7a57803fa830ef8f9cefff6

Also, note that Christopher's is the default transaction ID when you go to
the site.

If you are feeling very reckless, feel free to play with my tool for
generating BTCR DIDs. Please don't use it in mainnet mode unless you are
very confident you know what you are doing. It's only been tested once,
which is when I created mine.
Received on Tuesday, 18 July 2017 07:39:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:44 UTC