Editor's note, September 2022: This DID method works. There are reasonable, tested - libraries for it in - python and - java. It is convenient to use with - DIDComm v2. It is in active use - within the Hyperledger Aries community, among other places, and has gravitas and momentum there. However, it is - not required when using DIDComm, and since peer DIDs were described, some methods with partly overlapping - functionality have become more popular. In addition, the method predates the formal DID standard - by almost two years; when the DID spec became a TR, it became desirable to update a couple details here - that were out of alignment. That work hasn't been done. -
-We are not formally deprecating the method. It represents an important milestone in - our explorations of what is possible with DIDs, and it still delivers value. However, we want people to be - aware that new work may be better focused on alternative methods. If you care about endpoints, sophisticated - delegation, multisig, and key rotation, we recommend getting the features of peer DIDs wth - did:keri. If - you don't care about endpoints at all, and you don't plan to rotate keys, then - did:key may be a good choice. - Or you can continue to use this method. It's not going away; it just won't get a lot of attention going - forward. -
This document defines a "peer" DID Method that conforms to the DID Spec. The method can be used independent of any central source of truth, and is intended to be cheap, fast, scalable, and secure. It is suitable for most private relationships between people, organizations, and things. We expect that peer-to-peer relationships in every blockchain ecosystem can benefit by offloading pairwise and n-wise relationships to peer DIDs.
+There are reasonable, tested did:peer libraries for + python and + java. It is convenient to use with + DIDComm v2.