DID and SSI without blockchain / DLT?

[aschrijver]

The DID spec states (bold part mine):

Globally distributed ledgers (or a decentralized P2P network that provides similar capabilities) provide a means for managing a root of trust with neither centralized authority nor a single point of failure.

I am interested in solutions / references to DID / SSI that are not based on blockchain technology. Everything I so far encountered in my searches seem to require it. Is DID / SSI mostly progressing with blockchain as a requirement, or are there other worthwhile initiatives that go without it?

[ChristopherA]

There is a IPFS method for DIDs that is decentralized but doesn't have a blockchain — I'm not sure how active it is.

In general, there is no reason why you can't have a DID for variety of centralized things. You could have a did:vin:4T1BE46KX7U511384 which returns a DID Document with some unique public keys for that car, and list a service endpoint that points to the kind of data you get from https://driving-tests.org/vin-decoder/ — there can even be CRU(D/R) operations for such a centralized approach.

What we've found that you can do CRU(D/R) (create, read, update, delete/revoke) with centralized systems, but without a blockchain doing an update, delete/revoke is very hard. For instance, using IPFS you can create and read relatively easily, but you can't update the keys, delete or or revoke the keys as the content addressable hash changes, and thus you have to create another layer to announce it. Same is true with using PGP keys as DIDs — you have to create another layer for announcements as changing the key changes the fingerprint.

What blockchain/DLT tech offers to identifiers is that we can have them be persistent over time, but also allow them to have the update, delete/revoke operations that a centralized system can offer, but do so in a decentralized way. That is why almost all DID methods use a blockchain or DLT.

[aschrijver]

Thank you, @ChristopherA for your valuable explanation. I'll continue to be on the lookout for non-blockchain impls and combinations with other P2P tech.

[rschulman]

I'd be curious if anyone else is working on the IPFS solution to this. I think using the IPNS hash to point to a document with a history of DID documents solves the UD portion of CRUD without adding too much cruft but I haven't tried to spec it out completely.

On December 12, 2018 12:37:25 PM EST, Christopher Allen notifications@github.com wrote:

There is a IPFS method for DIDs that is decentralized but doesn't have a blockchain — I'm not sure how active it is. >

In general, there is no reason why you can't have a DID for variety of centralized things. You could have a did:vin:4T1BE46KX7U511384 which returns a DID Document with some unique public keys for that car, and list a service endpoint that points to the kind of data you get from https://driving-tests.org/vin-decoder/ — there can even be CRU(D/R) operations for such a centralized approach.>

What we've found that you can do CRU(D/R) (create, read, update, delete/revoke) with centralized systems, but without a blockchain doing an update, delete/revoke is very hard. For instance, using IPFS you can create and read relatively easily, but you can't update the keys, delete or or revoke the keys as the content addressable hash changes, and thus you have to create another layer to announce it. Same is true with using PGP keys as DIDs — you have to create another layer for announcements as changing the key changes the fingerprint.>

What blockchain/DLT tech offers to identifiers is that we can have them be persistent over time, but also allow them to have the update, delete/revoke operations that a centralized system can offer, but do so in a decentralized way. That is why almost all DID methods use a blockchain or DLT.>

-- > You are receiving this because you are subscribed to this thread.> Reply to this email directly or view it on GitHub:> https://github.com/w3c-ccg/did-spec/issues/113#issuecomment-446675526

[peacekeeper]

Besides the IPFS example mentioned by @ChristopherA , there are several other ideas for non-blockchain-based DIDs, e.g.:

1. At the Hyperledger Indy project, there's a lot of innovation happening around the concept of off-ledger DIDs that exist on a "microledger" which represents a relationship between agents; in this case the DID document, DID resolution, and the CRUD operations would all happen not on a public ledger, but only between the agents that form the relationship, using an agent-to-agent protocol (e.g. @dhh1128 proposed this here and has some great slides here).
2. There has been some discussion whether public keys could simply be "wrapped" into the DID syntax, i.e. the DID itself would be a public key, and DID resolution would be trivial and not require any network interaction. Such DIDs would not support Update/Delete operations (e.g. see here for an example, and here for a discussion).

[aschrijver]

Thanks @peacekeeper Some great resources provided here.

[jonnycrunch]

@jonnycrunch just adding myself to the conversation. I created the IPID DID method spec. It is still actively being developed. In the end, it simply publishes the DID document to IPNS as IPLD. see: https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/draft-documents/ipld_did_documents.md. I am waiting to get feedback regarding this approach and trying to get my issues addressed regarding the security short-comings of the DID spec in general.

[jwerle]

@rschulman we're leveraging the DAT network instead of a DLT and do indeed use the ed25519 public key as the identifier. We address the ddo.json file in our filesystem, which is signed by the secret key corresponding to the DID identifier. Our DIDs look like this: did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772 and resolve to documents like:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
  "publicKey": [
    {
      "id": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772#owner",
      "type": "Ed25519VerificationKey2018",
      "owner": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
      "controller": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
      "publicKeyHex": "27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nCfAWfEuWBIJiHb3PL3s0TuTnm/jSGdP/tGJCet2j6dy\n-----END PUBLIC KEY-----",
      "publicKeyBase58": "3gB1yDG6DdfHjMvQujUNZwA7CcwZbNatA7bi23jLpwvH",
      "publicKeyBase64": "CfAWfEuWBIJiHb3PL3s0TuTnm/jSGdP/tGJCet2j6dy"
    },
    {
      "id": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772#eth",
      "type": "Secp256k1VerificationKey2018",
      "owner": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
      "controller": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772",
      "publicKeyHex": "c6e42759c641f8499a2ffe93d23f5ada64bf62453ba39de712b2f3640110b4c6a7229fef5f066e0e46fcaa3ee9586068be6950fe525de690806a31299f972e13",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nDG5CdZxkH4SZov/pPSP1raZL9iRTujnecSsvNkARC0xqcin+9fBm4ORvyqPulYYGi+aVD+Ul3mkIBqMSmfly4T\n-----END PUBLIC KEY-----",
      "publicKeyBase58": "4ydrXgt2Myauc2anaRU17hpwZqUpmtCWaM3S1dUNRdatLMFVPCsrR6XK2zuoTaNYhpeSVk7H3vpEw9tUGUVKsL4A",
      "publicKeyBase64": "DG5CdZxkH4SZov/pPSP1raZL9iRTujnecSsvNkARC0xqcin+9fBm4ORvyqPulYYGi+aVD+Ul3mkIBqMSmfly4T"
    }
  ],
  "authentication": [
    {
      "publicKey": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772#owner",
      "type": "Ed25519SignatureAuthentication2018"
    },
    {
      "publicKey": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772#eth",
      "type": "Secp256k1SignatureAuthentication2018"
    }
  ],
  "service": [],
  "created": "2018-12-17T15:55:05.463Z",
  "updated": "2019-02-05T05:27:22.919Z",
  "proof": {
    "type": "Ed25519VerificationKey2018",
    "nonce": "1cc4f07dca31491d41638a6e260707ef75f955583c36c3fac51da43189e59d96",
    "domain": "ara",
    "created": "2019-02-05T05:27:22.921Z",
    "creator": "did:ara:27c059f12e5812098876f73cbdecd13b939e6fe348674ffed18909eb768fa772#owner",
    "signatureValue": "96736984d1727686f3d2fe0ddc26b1ef4e82f1e88c2cf257056193994b8a248f856ce63e67759863064138ee59c39104194914d153373762ca770641bac37208"
  }
}

[rschulman]

That's very interesting, @jwerle. Who is the "we" behind the dat implementation that you meantion?

[ChristopherA]

On Tue, Feb 5, 2019 at 8:41 AM Joseph Werle notifications@github.com wrote:

do indeed use the ed25519 public key as the identifier

In your approach, how to you rotate/update the public key in the identifier?

-- Christopher Allen

[jwerle]

@rschulman a project I'm working on with a few folks over at https://ara.one

@christophera we don't. We update the #owner and rotate others as needed without the identifier changing. We rely on the DDO signature for integrity, which should be signed by the owners secret key.

We are exploring options to help with eventual consistency, like DLTs, but did not make this a requirement for our DID implementation.

[RieksJ]

There's IRMA, which is an SSI system that does not use blockchain, and is operational software - it even seems to be actually used.

[peacekeeper]

@aschrijver I think your question has been answered? If you agree, could you close this issue? Otherwise feel free to add more comments/questions!

[aschrijver]

Yes, thanks everyone. Closing.