Cheap DIDs and the option to migrate DIDs between ledgers using standard DID Deprecation Registries

[pepoospina]

The motivation

I want to create a cheap DID with the simplest possible authentication method of a private-public key pair of a given algorithm, say:

did:secp256k1:pubkey

The DID Document would be null and thus assumed to have only one authentication element corresponding to the public key and the algorithm of the DID itself.

I want this so that I don't have to pay for storing the DID Document on a ledger, or trust that a cheap ledger will remain to exist forever.

Now I want to be able to, at some point, update this DID1 to a new DID2 that do lives on a ledger, and thus, has more complex authentication and authorization options.

So, how can a client verifying the DID1 would know that this DID1 was deprecated and should now look for DID2?

The proposal

Using a stable ledger (I would say Ethereum for simplicity of the implementation), create a default/standard public DID Deprecation Registry (ETH-DIDDR) smart contract to which the client can go and check if a given DID has been deprecated for a new one.

The DID1 owner will be able to add an entry into the ETH-DIDDR by signing (with the current DID private key) the number of a block that is not more than 1 day old (at the block the TX is added to the blockchain). This will create an indexed Event with the deprecated DID1, the signature and the new DID2 so that the client can easily search for it.

Some asides

• The not older than 1 day would give the paece of mind to the DID owner that any vulnerabilty that occurred more than 1 days ago (say selling a mobile phone without deleting the key) is not a vulnerability anymore.

• Clients could give a grace period of 1 or 2 weeks after the DIDDR is updated in which they still request authentication with DID1, to let the user of a stolen key to protect himself from the breach by contacting the client and explaining the situation.

• This DIDDR would also serve as a way to migrate a DID from one ledger to another one.

• There could be more than one DIDDR on multiple stable platforms.

[pepoospina]

Just saw the Allow DID methods without Update and Delete PR and the comment from @cbruguera proposing a revocation registry.

To me, these look like simple useful things that will be implemented one way or another.

In our case (a matrix.org-like protocol for content cocreation) this is a MUST, because:

• We will be generating many DIDs (for new users that dont hold DIDs themselves) and we dont have the means nor reasons to pay for them.

• We want control over these DIDs that we generate to be, at some point, transferred to the users in case they want it.

[peacekeeper]

Jose, I'm sure you're also aware of some of the DID work that the uPort team is doing, e.g. their secp256k1 method and their ethr method, I think those have some similarities with what you are proposing.

I think these are perfectly valid DID methods that are very interesting for certain use cases. I have just two small comments:

The DID Document would be null and thus assumed to have only one authentication element corresponding to the public key and the algorithm of the DID itself.

I suggest a small language change here... It's bit misleading to say that the DID Document is null. In this case there would still be a DID Document, albeit a "virtual" one that is dynamically constructed when the DID is resolved.

The DID1 owner will be able to add an entry into the ETH-DIDDR by signing (with the current DID private key) the number of a block that is not more than 1 day old (at the block the TX is added to the blockchain). This will create an indexed Event with the deprecated DID1, the signature and the new DID2 so that the client can easily search for it.

You may want to consider thinking about this as just an "update" operation executed on DID1, rather than deprecating DID1 and creating a new DID2. In other words, after the process you describe, the original DID would remain the same, but its DID Document as well as authentication / authorization properties have changed. You could rename "DID Deprecation Registry" to "DID Update Registry". It would still work the way you are describing. Do you see any downsides of this perspective?

[pepoospina]

Actually, I was not aware of that, thanks!

I agree on the language suggestion. "Virtual" seems a better word. But I don't think I am in a position to make this a formal proposal since I am new to this subject.

Regarding your comment on UPDATE, I wonder if the UPDATE operation can be used to update the id attribute of a DID Document. Do you know if this is the case?

What would a resolver do if it gets a DID Document of did1 that contains id = did2? Should it run the resolution again (potentially on another ledger) but with the new did2 and consider that DID Document as the effective one? Should the new DID Document be merged with the original one?

In this case a DID Update Registry would not be needed if you want to update a DID that lives in a platform that allows for these kind of DID Subject updates. Like updating from uport method to another method (potentially outside of ethereum).

The global DID Update Registry (living in ethereum) would be useful to help ledgers without scripting capabilities like IPFS or a pure SECP256K1 DID.

What do you think?

[pepoospina]

It's weird.

Documentation of uport-did-resolver shows a DID Document example in which the id is indeed different from the input did.

However, if you look at the resolver code, the id seems to be hardcoded to the input did as it is an input to the wrapDidDocument function and used without modification as the id of the doc.

@pelle might help us clarify if it is indeed possible to have a DID Document of a did with an id attribute different from the did.

[peacekeeper]

Regarding your comment on UPDATE, I wonder if the UPDATE operation can be used to update the id attribute of a DID Document. Do you know if this is the case?

One fundamental property of DIDs is persistence. The "id" property in a DID Document MUST contain the original DID that is being resolved, and this cannot change.

What would a resolver do if it gets a DID Document of did1 that contains id = did2? Should it run the resolution again (potentially on another ledger) but with the new did2 and consider that DID Document as the effective one? Should the new DID Document be merged with the original one?

The resolver would throw an error in this situation.

I probably didn't explain my suggestion well enough. I tried to suggest that you don't need to create a new DID2 at all. You can just keep and update the DID1, using the mechanisms you describe.

[pepoospina]

Oh, I got it now. Sorry.

It seems this would

1. solve my problem.
2. make the DID Update Registry more complex (similar to the complexity of uport-registry instead of a simple signed did to did mapping).
3. not serve as a way to migrate any did from one method to another.

I like (1), don't get me wrong :).

But (2) and (3) make me feel a bit uncomfortable because with a simpler DID Update Registry (2) I would also get (3), and thus decouple the Identity of an entity from the original ledger in which it is created.

[pepoospina]

Hi @peacekeeper, after further thoughts I now understand your proposal. A default DID Update Registry which is used to build the DID Document of stateless dids (like did:secp256k1) is the way to go.

We can also reuse part of the code from uport registry.

Deprecation can easily be added in the DID Standard as a new deprecatedBy: did2:newmethod entry, and jump from one ledger to another, without needing a DID Deprecation Registry.

I added this other issue on the java universal resolver repo for adding DID as an authentication provider for Spring Security. Maybe you have some comments.

[jandrieu]

Closing because we've moved it to the DID WG did-spec repo.