Use-case for generating DIDs for one-to-one relationships

[DurandA]

I fail to understand the use case for one DID per service/usage (e.g. pseudonymous DIDs or 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 as the identity is only shared with one other party. 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 (or sending the JSON DID document directly) 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?

I asked the question on Stack Exchange but it didn't grab much interest.

[TallTed]

One answer: 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.

Perhaps that helps?

[DurandA]

Thanks @TallTed for your answer. I do understand the benefits of minting new DIDs for privacy. However I still fail to understand why (D)IDs needs to be decentralized/stored on a blockchain for one-to-one relationships.

[dlongley]

@DurandA,

I do understand the benefits of minting new DIDs for privacy. However I still fail to understand why (D)IDs needs to be decentralized/stored on a blockchain for one-to-one relationships.

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 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).

[DurandA]

@dlongley Thanks, that was the answer I was looking for.

I will close the issue as it is more of a discussion than an issue with the specs. Feel free to post your answer on Stack Exchange if you want to grab the bounty.

[agropper]

We can consider this issue in terms of “Who bears how much of the cost?”

When a subject first approaches a service provider, the subject is exercising control based on choice. If the service provider demands a higher level of “trust” then the subject can factor-in the cost of using a VDR as part of a same-domain credential.

• If the subject does not have a choice, then the relying party can pass the economic and privacy costs of using a VDR or even requesting verified identity and non-repudiable identity on to (their) subject. This kind of power asymmetry can make SSI be self-sovereign in name only.

• The relying party need not make a demand but simply allow the subject to choose the degree of verifiabiliity and future linkability of their same-domain identifier. In this case, the subject retains the choice to escalate “trust” if justified and bear the incremental costs as they arise.

I don’t see any way to short-cut this reality. The self-sovereign subject needs to protect their exposure to much more powerful relying parties and any DID method that does not offer an effective and cost-effective path from same-domain to “trusted” identity will not be able to compete.

• Adrian

On Tue, Apr 27, 2021 at 10:53 AM Dave Longley @.***> wrote:

@DurandA https://github.com/DurandA,

I do understand the benefits of minting new DIDs for privacy. However I still fail to understand why (D)IDs needs to be decentralized/stored on a blockchain for one-to-one relationships.

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 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).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/did-core/issues/726#issuecomment-827716865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YLIYRNV7UIQNPNBINTTK3MVXANCNFSM43UA2HFQ .