Use-case for decentralized identifiers (DIDs) with unique identities for each relationship

Question

The W3C working group is working on the standardization of Decentralized Identifiers (DIDs). I watched a video presentation about DIDs and the presenter mentioned several times the possibility of generating unique pseudonymous identities for each relationship for better privacy. This is something that is also mentioned in the W3C documents (#1).

However, I fail to understand the use case for one DID per service/usage (e.g. online shopper with direct relationship between customer and seller). This looks like an example of direct trust where there is no need for a consistent global storage like a blockchain. To my understanding, the whole point of having DIDs is to have identities that are shared with multiple other entities.

For one-to-one relationships between a user and a service, won't a simple proof-of-possession token provide the same security guarantees at a fraction of the cost? What are the advantages of using unique DIDs for direct relationships versus storing public keys/identities on both ends?

This question has also been asked (and answered) on the W3C DID WG Issues page.

Answer 1

One answer (which was cross-posted to the W3C DID WG Issues page where this question was also cross-posted): There is always some correlation risk when an individual entity uses the same identifier for themselves, for interactions with multiple other entities, or even for multiple interactions with one other entity. Multiple strategies are used to minimize that risk in the universe of DIDs, but it still exists. It increases when some of the other entities merge, as in the business world, or when a governmental entity takes and combines the records of the other entities, as in some repressive regimes.

If the individual entity mints a new DID, for each interaction with an external entity, or for each external entity they interact with, potentially using multiple DID schemes along the way, that individual is adding another layer (or more) to the correlation mitigation strategies.

It is desirable for everything to be visible, in the universes of some entities. It is desirable for less, down to as close to nothing as possible, to be visible, in the universes of other entities. We cannot make the determination of what is best for all entities, but we can offer a range of options such that each entity can, with some effort, make their own determination -- which may change, as time goes on.

As to "replacing your FAX number", as @ThoriumBR suggests -- sure, you can give each external entity the same FAX number, or you can give each external entity a different FAX number, at (hopefully) minimal if ay additional cost, all of which reach you, as if they were the same number, but without providing the correlation detail discussed above.

Perhaps that helps?

Answer 2

You made me watch a 80 minute video...

And there's a blockchain. Not one, but more than one.

There's 5 categories of DID:

1. Ledger based DID: the original DID

2. Ledger middleware (Layer-2) DID: uses a storage layer over the DID blockchain. It should work like the Layer-2 protocols on Ethereum blockchain.

3. Peer DIDs: it's like a permissioned blockchain. A couple peers band together and they trust each other and nobody else.

4. Static DID: can be created (they are just a signed file) but they cannot ever change, nor be deactivated.

5. Alternative DID: everything else.

So you can create a DID for yourself, store it in one of those blockchains, and be happy. The DID never change even when your keys expire and you issue new ones, because you can update the DID with the new key: you sign the update with the current key while creating the new DID. So it proves you had the original private key and the new one.

In this sense, you would be able to have an instant login on any service: you provide your DID, the service sends you a challenge, you sign that challenge, the service checks the signature and have immediate access to any information you set as public on your DID: mail, name, country, things like that.

Now to your question.

There's the seller blockchain (or product, or marketplace, or the Universal Federated Chamber of Commerce Blockchain). This one can be a ledger based, using one of the myriad existing blockchains or a new one created just for that. The product is entered on the blockchain when it's created, and every time it changes hands, its status is updated on the blockchain.

When Merri wants to buy the card, she can check the entire history of the product since it was made, every time it was sold, and knows for sure that the card is legit.

Knows for sure here depends on how trustworthy is the process to update the blockchain, or someone can claim ownership of the Eiffel Tower, for example.

I believe the idea is to have an unique way to identify people around, in place of logins, usernames and emails. I don't see much of an improvement on the privacy area, because blockchains and privacy on the same place is a strange arrangement.

And it's kind of TLS for people. You can know for sure that a DID from Alice will have Alice's public key and wasn't tempered with.

Answer 3

DIDs needn't necessarily have a backing verifiable data registry (e.g., blockchain, decentralized ledger). So that isn't a requirement -- and the use case you highlight may be a good case where one is not necessary. However, also consider that even in some one-to-one relationships, the relying/verifying party may trust a verifiable data registry's view of changes to the DID Document more than whatever an individual may announce.

There are a class of attacks where the DID controller could misrepresent changes to their DID Document that may be important to the relying party to mitigate via a trusted registry or set of witnesses (that is/are not under the sole control of the DID controller). Similarly, the DID controller may also prefer to have a trusted registry/set of witnesses available to vouch for their changes should there be any dispute.