Microsoft Launches Decentralized Identity Tool on Bitcoin Blockchain

#1

I’m discovering today what is the difference between Microsoft’s DID and blockchain’s SSID.

ANSWER: From what I can tell, Microsoft will sell you a combination IPFS/Bitcoin server that logs your change events to the bitcoin blockchain. Not bad.

looks like Blockstack has had similar functionality since June 2018:

The article of interest:

1 Like
#2

Yeah I’m still investigating but I asked Microsoft a few questions here: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Toward-scalable-decentralized-identifier-systems/bc-p/565076#M1142

1 Like
#3

Awesome! It come out quite late than expected but we all know they will join the game. We will have many many competitors (those are quietly/privately building their project too).

The only way to win is become the best. Blockstack could be come something or nothing. I’m so excited!

For community, Blockstack is belong to you guys. Win or lose are on you! Moving fast guys!

#4

@jude, @ginxh As mentioned in the engineering meeting yesterday, my interested is about how/if/when blockstack will integrate the sidetree protocol, how the gaia protocol and the DCAS Rest Interface fit together.

1 Like
#5

@colealbon I don’t think the properties of ION DIDs are important here or should be compared (what encryption methods, did format, etc…). It is more important that the project uses the Sidetree protocol. It will allow services to discover DIDs across blockchains using a unified REST API. Blockstack Subdomains could benefit from that maybe.

#6

From what I can tell, the sidetree nodes do not eagerly replicate DID operations to one another and may even unpin previously-processed state, thereby making it impossible for new nodes to reconstruct the state of all DIDs. The system’s reliance on IPFS to distribute DID operation logs means that anyone in the world can trivially disrupt a public-use sidetree deployment by polluting the IPFS routing tables and rendering DID update log chunks unresolvable.

I’m also surprised that the DID working groups don’t allow human-readable names in their DIDs, despite the fact that doing so makes them easier to remember (i.e. judecn.id versusdid:stack:v0:1KVzcgurJmTr4Cr44h6raEVtoGhm7ZZxzm-0). This is surprising because DIDs are not content-addresses – the data they point to is meant to change, so the DID string itself doesn’t need to be derived from the DID document.

Looking through the DIF Github, some folks seem interested in adding did:facebook as a DID method. This seems counterproductive to me because the whole point of decentralized identifiers is to move away from implementing identity systems that depend on a specific instance of an administrative domain (e.g. Facebook Inc). It also looks like I’m not the only one surprised by this development.

3 Likes
#7

Great comments Jude!

I spent a little time looking at ION and came to similar conclusions. I asked a few questions here: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Toward-scalable-decentralized-identifier-systems/bc-p/567360#M1172 .

The things I DO NOT like about the protocol:

  1. IDs are not friendly names
  2. IDs are non-transferable
  3. global state is strongly eventually consistent
  4. IPFS pinning game theory

The things I DO like:
[ but these don’t necessarily have to be in the protocol ( it can be implemented at the application or a middleware layer (like Radiks) ]

  1. Concepts on structured data i.e schema.org and JSON-LD. I think this will be implented in Blockstacks implementation of “Collections”
  2. Saving data using git-like (CRDT) commits (can be built on top of getFile or putFile). My app implements this on the application layer using automerge.js
1 Like
#8

ION is an implementation of the sidetree protocol, the protocol does not define which storage to use. Therefore, I think IPFS is not the selling point here, just the easiest to implement.

I see.

I see DIDs similar to IP addresses, nobody but the protocol implementer cares. And as an app developer, I don’t want to get into the sign in button stack again. Therefore, for me it makes sense to have interoperability between identity providers and an unified API for authenticating users.

It is a good thing that private keys (that is how you prove your DID) are not transferable. How these keys are mapped to something useful is up to the identity providers, also whether this “something useful” (e.g. Blockstack IDs) are transferable or not.

#9

IDs are non-transferable

It is a good thing that private keys (that is how you prove your DID) are not transferable.

Actually, they are transferable. At least, the spec requires an update method that changes the public key(s) in the DID document. Edited my earlier comment to reflect this.

1 Like