Difference between revisions of "Sidetree"
(→Context) |
(→Context) |
||
| Line 2: | Line 2: | ||
[[Sidetree]] is a spec for a collection of [[Distributed ID]] methods that uses IPFS to guarantee uniqueness of a DID. | [[Sidetree]] is a spec for a collection of [[Distributed ID]] methods that uses IPFS to guarantee uniqueness of a DID. | ||
==Context== | ==Context== | ||
| − | Microsoft started to build [[Sidetree]] as the backing for the [[Ion | + | Microsoft started to build [[Sidetree]] as the backing for the [[Ion ID]] (did:ion) method to improve responsiveness to reads and writes of ID data. |
* Sidetree basically intercepts any request for ID reads or writes and tries to cache them to avoid a delay caused by a read or write to the Bitcoin Blockchain. | * Sidetree basically intercepts any request for ID reads or writes and tries to cache them to avoid a delay caused by a read or write to the Bitcoin Blockchain. | ||
Latest revision as of 16:59, 1 December 2021
Full Title
Sidetree is a spec for a collection of Distributed ID methods that uses IPFS to guarantee uniqueness of a DID.
Context
Microsoft started to build Sidetree as the backing for the Ion ID (did:ion) method to improve responsiveness to reads and writes of ID data.
- Sidetree basically intercepts any request for ID reads or writes and tries to cache them to avoid a delay caused by a read or write to the Bitcoin Blockchain.
Problems
- As of 2020-11-15 the Sidetree spec did not guarantee that an old key used for signing or encryptions would be available from any of their methods.
- As of 2020-11-15 the IPFS implementations were at Alpha release level and not recommended for production use.
- As of 2020-11-15 the Sidetree spec required two versions of the DID and stipulated that any RP relying on that DID would have to accept either version interchangeably.
- The Sidetree folk introduced the idea of "equivalent" IDs (see above problem) into the DID Core spec just before it went to be a candidate (2021-04-01) This makes extra work for the RP with no benefit to the RP other than an expansion of the number of did methods that they can accept.
- Final Sidetree v1.0.0 spec has no date in the doc itself but the current history in GitHub reports 2021-03-26.
Solutions
What is Sidetree?
Self-issued identifiers, for example, Decentralized identifiers (DIDs) enable a person or entity to securely authenticate, demonstrate intent and exchange data, where the identifier is being managed independently of those systems and organizations. DID events such as creation, updates, and revocations can be organized and propagated by DID networks. Sidetree describes a protocol for building such networks without being coupled to a particular underlying ledger or event record system. The protocol and data model described by Sidetree enables a decentralized identifier model that allows its user to ultimately be in control of the identifier and its history, without introducing additional trust requirements beyond the underlying event record system. Sidetree-based networks can be implemented on top of a wide variety of event record and propagation methodologies(public Blockchains, Federation and witness protocols, or Permissioned Blockchains) and can be as open as the underlying mechanism. Sidetree enables a scalable protocol, that can be overlaid on a variety of event record and propagation systems, for creating vibrant digital ecosystems based on decentralized identifiers
from Troy Ronda 2021-04-02
- Microsoft introduced did:ion with sidetone and BitCoin support after four years of work. [1]
- SecureKey Implementations
- https://github.com/trustbloc/sidetree-core-go: Ledger-agnostic Go implementation of Sidetree
- withOrb (https://github.com/trustbloc/orb) and Hyperledger Fabric
- variations built on top.
References
- ↑ Pamela Dingle, ION – We Have Liftoff!, Microsoft (2021-03-25) https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555
