Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DID and SSI without blockchain / DLT? #113

Closed
aschrijver opened this issue Dec 11, 2018 · 13 comments

Comments

Projects
None yet
8 participants
@aschrijver
Copy link

commented Dec 11, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Author

commented Dec 13, 2018

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

This comment has been minimized.

Copy link

commented Jan 3, 2019

@peacekeeper

This comment has been minimized.

Copy link
Member

commented Jan 7, 2019

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

This comment has been minimized.

Copy link
Author

commented Jan 7, 2019

Thanks @peacekeeper Some great resources provided here.

@rhiaro rhiaro added the question label Jan 25, 2019

@jonnycrunch

This comment has been minimized.

Copy link

commented Jan 31, 2019

@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

This comment has been minimized.

Copy link

commented Feb 5, 2019

@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

This comment has been minimized.

Copy link

commented Feb 5, 2019

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

@ChristopherA

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2019

@jwerle

This comment has been minimized.

Copy link

commented Feb 6, 2019

@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

This comment has been minimized.

Copy link

commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 11, 2019

@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

This comment has been minimized.

Copy link
Author

commented Jun 11, 2019

Yes, thanks everyone. Closing.

@aschrijver aschrijver closed this Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.