Re: "anybody can ledgerize" vulnerability

The "market solution" proposed is "whomever pays us to publish"? Or
"whomever advertises and attracts customers?" The second is bad because of
IEO and ICO incentives.

My personal preference would be collectives of trust. If people are forming
relationships and they are mutually responsible to each other, and the
clients could treat a group as credible or not, we have the same simplicity
as many other solutions proposed but now the game theory incentivizes self
policing within a group. It may be a small force, large companies may be
corrupt, but clients could and should decide how much to trust each group.
An individual could and should be signed by more than one authority, and so
honest participation is mutually rewarded.

I would like to know in more detail what this group thinks a "market
solution" is for trusting certificate authority in DID. Furthermore, is the
intention to make a credible system as mainstream proof of identity or just
facilitate trade?

On Thu, Sep 19, 2019, 11:11 AM ProSapien Sam Smith <sam@prosapien.com>
wrote:

>
> Some additional comments:
>
>
> The problem is that the DID Spec in its current form is sufficiently
> ambiguous that it does not require self-certifiability but implies
> (dangerously so) that complying with the spec without self-certifiability
> is sufficient.
>
> Proving control of a DID, i.e., the binding between the DID and the DID
> Document that describes it, requires a two step process:
>
>    1. Resolving the DID to a DID Document according to its DID method
>    specification.
>    2. Verifying that the id property of the resulting DID Document
>    matches the DID that was resolved.
>
>
>
> This issue came up because the did:peer method  was designed to be
> private and not put on a ledger, however, the current formulation of the
> did:peer method suffers from the "anyone can ledgerize" vulnerability
> precisely because it is not self-certifying.  So the ambiguity in the spec
> is a problem.
>
> For example Veres one goes beyond the specification by ensuring that a
> fingerprint of the verifiying key pair is in the DID itself. (ie is
> self-certifiable)
> Quoting Dave Longely:
> "Veres One (v1) protects against this by requiring the DID itself to be
> derived from key material. A Veres One "nym" (short for cryptonym) DID
> must be derived from one of the `capabilityInvocation` keys expressed in
> its associated DID Document. The act of registering the DID requires
> that the DID Document itself be invoked as a capability
> ("self-registration"). This invocation can only be performed by whomever
> controls the private key material associated with a
> `capabilityInvocation` key, and specifically, the DID itself must have a
> fingerprint (or full public key material) that matches that key.
> "
>
> A reasonable interpretation of the spec language allows one to NOT include
> a fingerprint of the public key from the public/private key pair used to
> sign the did document in the DID itself.
> Merely that the id property matches the did  but the id property could be
> anything and does not have to be cryptographically linked to the signing
> key material provided in the did doc .
>
> This creates a race condition. As anyone can create key material and
> register the DID (create method) with a DID resolver. Because DID resolvers
> are decentralized it is up to the did resolver to decide which DID docs to
> cache and which to not and if one wants to make sure one's did doc is
> discoverable one has to register it it widely.  So a malicious party could
> observe the registration of a DID at one resolver change the key material
> in the did: doc and then register the same did but with different did doc
> at  another resolver.  This is just another form of the anyone can
> ledgerize attack. Its the anyone can spoof a did to a given did resolver.
>
>
> Now  one way to stop the spoofing would be to add a ledger as a root of
> trust in the did method where the DID method requires that in order to
> CREATE a did at a resolver the resolver must first find the did on the
> ledger with its did:doc.
>
> But now the DID is not portable across ledgers as the root of trust is
> also the ledger not merely the controller of some private key.
>
> Fundamentally the mix of non-self-certifiability and decentralized control
> is problematic.  It is possible to build a did method on other roots of
> trust besides or in addition to self certifiability but its way more
> complicated.
>
> The main value of a decentralized identifier standard is to enable any
> entity to assert control over a namespace  without dependence on some other
> entity in an interoperable way.  The infrastructure of DIDs DID Documents
> and DID resolvers is to support than value.  But when the infrastructure is
> also decentralized it becomes problematic when there is not a consistent
> root of trust over the whole interoperable infrastructure.
>
>
> When the key material used to verify a did doc is not linked to the did
> itself then anyone can create a did doc for that did and use different key
> material. That is the problem.  When that happens there is no unique
> controller of the DID unless some other root of trust or authority
> specified in the DID method is invoked to determine the unique controller.
>
>
> Because DID specification punts the control of DID methods and DID method
> namespaces to a "market solution" removing self-certifiability opens up
> another lurking problem.   Frankly the market solution  may be the best
> we can do for now.  What this means is that DID resolvers get to decide
> which did methods for which did method names they will support. Different
> resolvers could decide to support a different method for the same method
> name given two different entities that wish to control the same method
> namespace. One hopes that the cost of maintaining a method name space makes
> method name squatting a rarity. One hopes that resolvers will have
> reputations that enable users to pick credible resolvers.
>
> But realistically :)
>
> There is incentive for a malicious entity to  confuse the did method and
> did method name from the standpoint of the user wishing to resolve a did at
> a given resolver.
>
> 1) A malicious attacker could substitute a malicious method into a local
> resolver.
>
> 2)  A universal resolver that allows automatic registration of DID methods
> would be a target for malicious did methods.
>
> 3) A business dispute between partners who have created a method namespace
> where there is no legal basis for who gets to control the method namespace.
> So the partners each spam new resolvers with a different version of the
> method.
>
> BUT in any case if the DID itself is self-certifying then attacks on
> methods at resolvers are limited because the user can always independently
> verify the root of trust in the did doc.  Removing that root of trust just
> opens a can of worms. Putting the root of trust solely  in the DID method
> does not close the can.
>
>
>
>
>