Some commets

A colleague of mine from Intel has been looking at the DID specification and had these comments.
He is waiting for approval from Intel to join the W3C working group. But I thought there might be interest in his comments.


> On 30 Apr 2018, at 18:22 , Smith, Ned <ned.smith@intel.com <mailto:ned.smith@intel.com>> wrote:
>  

> Also a nit: “an owner property, which identifies the entity that controls the corresponding private key. If this property is missing, it is assumed to be the DID subject.” Later in the document it says owner is essentially mandatory since parsers will complain if it is missing.  Seems like a contradiction to me.

> Also, the section on non-repudiation doesn’t mention anything to do with how the private key is protected (for example, if it is feasible for the key holder to make a copy and distribute it to other entities that may ascribe different proofs of authentication). I think people have changed the definition of non-repudiation over time to mean different things. The term was first used in the context of digital signature to imply legal non-repudiation could be supported. However, courts have thrown this out since asymmetric keys can exist in memory that is easily read by other legal persons. Even a rigorous process that ensures keys are securely migrated could result in the key being controlled by another legal person than the person who used it to sign. 
>  
> The use of non-repudiation for non-legal context generally applies to whether or not there are multiple instances of the key not under a common administrative control of the owner. By this definition even symmetric keys could exhibit non-repudiation as in Kerberos. Though some purist / asymmetric crypto bigots will use the legal non-repudiation definition to argue why symmetric keys couldn’t possess non-repudiation properties.
>  
> The definition in the spec seems to be describing something different from either of the above two definitions. I’m not sure of the definition but it appears to describe something about the lifecycle of the DID Document rather than the number of instances of the private key. Note, it is possible the private key could be used off-chain; hence it shouldn’t be assumed that by monitoring on-chain transactions that repudiation events can be detected. The DID definition is enough different that the document should acknowledge these other definitions and better craft a third definition and why it is relevant to DID (and why that definition is more relevant than existing definitions).
>  
> 7.6 I don’t believe keys should expire. The semantics are misstated. Expiration is for the binding of attributes to the key (not that the key is somehow weaker due to the passage of time). Revocation should be the only way to deal with compromised keys. Non-compromised keys should remain valid forever. This section should be named “DID Document Expiration” and wording adjusted accordingly.
>  
> 7.7 Conversely, the concept of revocation should be to the compromised key rather than the DID Document. I’m not suggesting that the DID Document should be believed subsequent to key compromise, but the semantics for how to deal with key compromise should be stated in terms of the compromised key primarily and the impact of compromised key may have on claims that no longer hold consequently should net secondary attention.
>  
> Privacy section 8.2 is being too bold about right to be forgotten because it presumes PII is crisply defined and understood. It should instead warn that all information is subject to differential privacy attack and therefore may be mathematically impossible to comply fully with the concept of “right to be forgotten”. However, reasonable steps are taken to allow users / owners to use available privacy protection tools with DIDs.
>  
> -Ned





Samuel M. Smith Ph.D.
Technical Governance Board
Sovrin Foundation
mobile: 1.801.592.8230
email: sam.smith@sovrin.org