Initiatation of DID methods, when you dont know what the user want to use

[vongohren]

I believe this is an interesting case for interopability. I did not want to write things twice, so I will just reference the main issue here. Then we can have a discussion on a more general level in this issue.

https://github.com/jolocom/smartwallet-app/issues/1502

Questions Is this a case that would happen in the future for services? As a service provider I should never have to choose the identity service? Is a https://iancoleman.io/bip39/ seed enough to cater to exportation of identity services? Do you have any other thoughts around this?

[OR13]

@vongohren

I have also encountered this issue.

We have some code in element that solves for this issue in sidetree based DID methods:

https://github.com/decentralized-identity/element/blob/master/packages/element-lib/src/crypto/MnemonicKeySystem.spec.js#L12

In sidetree case, we can predict what a DID will be based on its initial payload... There is ongoing work to formalize these "un-anchored" style DIDs: https://github.com/w3c/did-core/issues/70

There are a bunch of issues all tied up in here.

1. Deterministic process of converting HD Wallets to DIDs
2. Recovery / Revocation of un-anchored / not registered DIDs
3. Security issues around using mnemonics for portability

3 is easiest... Its become popular to use mnemonics for portability especially between MetaMask / Ledger, etc.... its pretty much like moving a private key... https://security.stackexchange.com/questions/101560/how-to-securely-send-private-keys

Assuming you are ok and trust all the middleware that will have access to the mnemonic...

we can now address 1.

For did:ethr, each node in an HD Wallet is a DID... even if its never been anchored / used on the ethereum network.

For sidetree based methods, there is an implied DID for all possible initial DID Documents signed by a node in an HD Wallet... thats a complicated way of saying the same thing, with lots more flexibility and a host of security issues I won't go into here.

Assuming you trust this paper... https://cardanolaunch.com/assets/Ed25519_BIP.pdf You can do the same thing with ed25519 and did:key....

Great you now have an unlimited number of DIDs connected to your HD Wallet for secp256k1 or ed25519....

Now what about recovery (2)...

For many DID Methods, recovery / revocation is a "registered", "anchored" or "ledgerized" process, which involves checking a registry on some trustless / permissioned ledger, and making an update to that registry...

The mnemonic can be used to recover the keys that can be used to revoke / recover the DID.

If the DID Method creation requires a transaction to a network like Ethereum / Bitcoin, and the transaction does not exist yet... we call this DID "not anchored" "not registered" or "unlederized".... This usually means there is nothing to recover, I believe this is the care you encountered.

There are systems out there that attempt to provide some workaround for this such as @SmithSamuelM 's KERI.

TL;DR; Mnemonics -> Public Keys -> DIDs, yields 2 cases, where DIDs exist regardless of a ledger transaction (did:ethr), or where a transaction is required to create the DID (did:jolo, did:btcr and current versions of did:ion and did:elem, though there is plan to support "unanchored" stuff in the future)...

What recovery means depends on which of these cases you end up in, and the specifics of the DID Method implementation.

I'd love to hear more from Sovereign about this @TelegramSam @kdenhartog

[SmithSamuelM]

@OR13 good overview of the issues.

To add my two cents. Lets break DIDs and DID Docs into two concepts.

1) Establishing authoritative control over an identifier (DID) as a set of authoritative signing keys.

2) Establishing authoritative control over everything else associated with the identifier

If you solve 1) then 2) becomes trivialized because 2 is accomplished by signing an attestation for anything in 2) using the authoritative keys established by 1).

The DID Doc complicates things because 1 and 2 are mixed together.

KERI is based on the concept that the primary root of trust for a self-certifying identifier is the incepting public private key pair for the identifier. A self certifying identifier is defined to be one that includes in the identifier itself a universally unique fingerprint of the incepting controlling public key. This fingerprint trivially could be the public key. Or it could be uniquely derived from the public key in an HDKey like manner including a hash of an inception data that includes the public key. Absent this self-certifying property there must be some other root of trust which means that the identifier is subject to the security, governance, and centralization effects of that other root of trust.

What KERI is attempting to do is make 1) a lower level activity via log of events that are universally verifiable that anyone can use to validate the state of 1) The primary purpose of 1) is to establish the chain of rotations from an inception event that defines a self-certifying public private key pair for the identifier to some later set of authoritative keys. In this model Ledgerization provides a secondary root of trust but is not needed as a primary root of trust.

This is confusing because many in this space only think of 1) as being established by ledgerization as the primary root of trust and not self-certification as the primary root of trust.

If self-certification is the primary root of trust then a did-doc can provide a snapshot of the state of 1) without being the root of trust. Likewise a ledger can be a witness of the log of events without being the primary root of trust.

The net effect is that using a KERI like process to establish 1) is DID method and ledger independent. This approach thereby enables truly portable DIDs. A DID whose key rotation history is locked to a ledger is not truly portable.

[SmithSamuelM]

The complications that @OR13 describes for recovering control of a DID or moving a DID between ledgers become simplified because the ledger is not the primary root of trust, the key event log is. and the key event log is just an ordered set of receipts of key events. Think multiply signed receipts. Each signature is another secondary root of trust. One can add ledger anchors to a given state of the event log at will and thereby move the identifier across ledgers. The witnesses to the event log can be rotated in the same events that one rotates keys so the full trust basis for each event is controlled by the same authitative set of keys. There is never any other primary root of trust. This greatly simplifies the security model and the DKMI.

[vongohren]

Wow this is great information! Cannot say I understand it all completely but it makes sense in many ways. Is there any where I can read more about KERI @SmithSamuelM?

If you guys could choose @SmithSamuelM @OR13, what would be a couple of next steps towards a better world on this?

[SmithSamuelM]

The KERI white paper is here. https://arxiv.org/abs/1907.02143 There is now a repo on DIF where an RFC for a standard proposal will be formed. https://github.com/decentralized-identity/keri There will be an Aries RFC upcoming to props the same thing

Idea is to get broad interoperability.

It was recently pointed out to me by Dave Huseby that KERI follows the same approach that the CA community eventually arrived at for verifying certificate authorities. That is a key event log. So its nice confirmation that it is best practice. Its called the Certificate Transparency project.

https://www.fastcompany.com/3042030/the-huge-web-security-loophole-that-most-people-dont-know-about-and-how-its-be https://queue.acm.org/detail.cfm?id=2668154 http://www.certificate-transparency.org/home https://www.eff.org/observatory

Quoting "Certificate Logs Certificate logs are simple network services that maintain cryptographically assured, publicly auditable, append-only records of certificates. Anyone can submit certificates to a log, although certificate authorities will likely be the foremost submitters. Likewise, anyone can query a log for a cryptographic proof, which can be used to verify that the log is behaving properly or verify that a particular certificate has been logged. The number of log servers doesn’t have to be large (say, much less than a thousand worldwide), and each could be operated independently by a CA, an ISP, or any other interested party."

What the Witnesses, Validator and Judge roles in KERI are similar to the Monitor and Auditor roles in, Certificate transparency. The difference with KERI is that its designed specifically for decentralized controllers of public/private keys vs certificate transparency which is designed for centralized controllers called certificate authorities (Public/Private Key = Public/Private Certificate)

[SmithSamuelM]

The other main difference is that each KERL (Key event receipt log) in KERI is dedicated to a specific identifier and may be used to independently verify the control authority for the identifier. Certificate Transparency does not have this capability but merely allows one to correlate or detect bad behavior by a certificate authority. So KERI IMHO is much better. It provides not just a proof of log but the log itself is a proof of authority.

[SmithSamuelM]

The essential insight is that the incepting authority for a cryptographic public private key pair is imbued by the random entropy/collision resistance used to generate the private key and then the one way function used to derive the associated public key. Thus to invoke the Highlander meme "There can be only one". From this singular root of trust, signed key rotation events can be used to transfer that trust to successive key pairs. The key event log then becomes a proof of authority for the latest key pairs from the latest rotation event. This requires no ledger or other root of trust. Merely an extant copy of a fully signed (receipted) immutable event log. This makes it truly universal.

[SmithSamuelM]

A certificate transparency log provide proof of inconsistent or duplicitous behavior by a CA not proof of authority of the CA. KERI provides decentralized proof of authority primarily and as a side benefit may be also used to provide proof of inconsistent behavior.

[vongohren]

Ok I see, I will dig into these papers a bit more to get the better gist of it @SmithSamuelM. But reading this I like the thought, but what differs from, lets take the ethr method. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1056.md Which uses log events on ethereum to create a log of what is happened, and resolves a did document from that?

Since the ethr method can live unanchored, and it just uses append only events, to build up itsthe history, then it supports itself on top of the DID spec, which allows for change ownership of identity, and other DID supported attributes, as you can see in the spec.

Im just asking these questions to get a better understanding of the different approaches. If you have a couple of main bullet points on the difference? It would be great to get, while I read the papers. I did a quick skimming through, you want the the key logs to be in controll of the controllers of the identity, rather than in a ledger like proposed in EIP-1056?

[SmithSamuelM]

There are a couple of important differences. But generally key rotations are "events" and verifying the current authoritative key set requires verifying the log of events. This means that we could have a standard set of events that is Ledger/Method independent. If the events are standard then they are portable. The problem now is that every DID method is using an incompatible set of events or not using events. The important differences is the authority for putting the events on ethereum is ethereum specific and is not currently portable to another ledger.

[OR13]

^ this is what I like about KERI so much... most of the DID Method operations (create, update, deactivate) are possible to model using domain driven design / event sourcing, and most of the DID Method implementations use some form of event sourcing to implement this functionality.

There is a possibility to offer a standard for these changes, that might help with inter method portability, and at the very least, provide better guidance to any future DID Method implementers.

[vongohren]

Aahh, i see. I understand how this can be valuble. But I would make a set of standard events, I can connect them to the ethr method if I want but also some other method.

But then in the end, where does these standardized event logs go? In your own repository? Or you put them on many random ledgers?

[SmithSamuelM]

KERI declares witnesses. Each witness has an immutable event receipt log. A witness could be a ledger. A key rotation event not only rotates keys but may rotate witnesses. What this means is the the controller of the identifier makes a cryptographic commitment to those Witnesses the controller trusts. At some point in the future the controller can change that set of trusted witnesses Via a rotation event and hence “port” their key event receipt logs to that new set. this is a generalized rotation event where one may rotate not just the Authoritative signing keys but the authoritative set of witnesses (ledgers) for establishing the chain of control for future rotation events. Anything less is an incomplete DKMI that due to this lack of witness portability is thereby inherently less self-sovereign in that the identifier is not truly portable. The identifier is locked to a given ledger because its key rotation authority is locked to that ledger.