Re: "anybody can ledgerize" vulnerability

A self-certifying identifier implies that the identifier is self-authenticating in that it includes the key material needed to authenticate itself (by virtue of the key material in the identifier) and then  the creator of the identifier may authorize via a signature with the associated private key  some action on that identifier such as creating a did doc. 

It appears that Veres One is self-certifying by including unique key material in the identifier and then requiring verification using that same key material before accepting the DID Doc. The is essentially the correct behavior. 

The act of not including the key material in the identifier itself removes the self-authentication feature. This lack is the source of the problem and exposes the vulnerability.  Eliminating self-authentication means that some other authority must authenticate the origination or inception event on the identifier. This can be a ledger but that means that the origination event or registration event on the ledger can be performed by anyone because the identifier is not uniquely bound to the key material used to register it. This creates a race condition (first to register) and allows someone to register or ledgerize the identifier unauthorized.  This is problem for private identifiers where the originator does not want the identifier ledgerized and therefore never registers it thereby opening the opportunity for someone else to ledgerize it. 

Requiring an external authority to authenticate identifiers in order to authorize actions of the identifier is inherently more centralized and opens a can of worms.  It matters not that the external authority is a permission-less ledger the identifier is still not self-authenticating.



> 
> 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.
> 
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.


Samuel M. Smith Ph.D.   Founder
smith.sam@prosapien.com 
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith
http://www.prosapien.com/ 

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message