Merge pull request #112 from daidoji/small-changes-to-keri

Some small changes to KERI.md section.

spec/keri.md

@@ -15,7 +15,7 @@ A KEL is a hash-chain append-only log and can be considered a variant of blockch
 1.  It records the [[ref: key event]] history of a single AID with a single [[ref: controller]], instead of an arbitrarily large collection updated by other participants in the network. This makes a KEL memory-efficient, fast, cheap, and trivially scalable.
 2.  It is fully [[ref: self-certifying]], meaning its correctness can be proved by direct inspection, without a distributed consensus algorithm or assumptions about trust in an external data source or its governance.
 
-These properties allows a KEL to be published anywhere, without special guarantees from its storage mechanism. For example, a KEL of an AID could be published on and migrated between different KERI-compatible blockchain networks that use different DID methods. A KEL also records changes to key types and cryptographic algorithms, providing the AID portability and adaptability to multiple ecosystems throughout its lifecycle.
+These properties allows a KEL to be published anywhere, without special guarantees from its storage mechanism. For example, a KEL of an AID could be published and migrated between different KERI-compatible blockchain networks that use different DID methods. A KEL also records changes to key types and cryptographic algorithms, providing the AID portability and adaptability to multiple ecosystems throughout its lifecycle.
 
 ### AID Derivation
 
@@ -43,17 +43,17 @@ Unlike a blockchain with a distributed consensus mechanism, witnesses do not coo
 
 ### Transaction Event Log (TEL)
 
-[[ref: KERI]] supports a official veriable data structure, called [[ref: transaction event log (TEL)]], that binds an [[ref: AID]] to important, non-repudible actions that must relate with deterministic order to the [[ref: key event]] history in the [[ref: KEL]]. Transactions that are recorded in a TEL include, for instance, issuance and revocation of verifiable credentials, started or stopped listening on a service endpoint. Like KELs, TELs are self-certifying and may also be published by witnesses to enhance discoverability and accountability.
+[[ref: KERI]] supports an official verifiable data structure, called the [[ref: transaction event log (TEL)]], that binds an [[ref: AID]] to important, non-repudiable actions that must relate with deterministic order to the [[ref: key event]] history in the [[ref: KEL]]. Transactions that are recorded in a TEL include, for instance, issuance and revocation of verifiable credentials, or the starting or stopping of listeners on a service endpoint. Like KELs, TELs are self-certifying and may also be published by witnesses to enhance discoverability and accountability.
 
 ### Web Independence
 
-Although _this DID method_ depends on web technology, _KERI itself_ does not. It's as easy to create AIDs on IOT devices as it is on the web. AIDs offer the same features regardless of their origin, and besides HTTP, they are shareable over Lo-Ra, Bluetooth, NFC, Low Earth Orbit satellite protocols, service buses on medical devices, and so forth. Thus, KERI's AIDs offer a bridge between a web-centric DID method and lower-level IOT ecosystems.
+Although _this DID method depends on web technology, KERI itself does not_. It's as easy to create AIDs on IOT devices as it is on the web. AIDs offer the same features regardless of their origin and besides HTTP, they are shareable over Lo-Ra, Bluetooth, NFC, Low Earth Orbit satellite protocols, service buses on medical devices, and so forth. Thus, KERI's AIDs offer a bridge between a web-centric DID method and lower-level IOT ecosystems.
 
 ### Flexible Serialization
 
 [[ref: KELs]] and [[ref: TELs]] of `did:webs` DIDs (i.e., AIDs) are included in the [[ref: KERI event streams]] for verification of the DID documents. The KERI event streams use [[ref: Composable Event Streaming Representation (CESR)]] for data serialization. Although CESR is a deep subject all by itself, at a high level, it has two essential properties:
 
-*   In CESR, multiple serialization formats including JSON, CBOR, and MsgPack are supported. Muliple formats can be freely mixed and combined because CESR makes each chunk of content self-describing. _A digital signature on a CESR data structure is stable no matter which format is used_. The practical effect is that developers get the best of both worlds: they can produce and consume data structures mostly using whatever toolset they like, they can displayed and debug data structures in a human-friendly form, and they can store or transmit data in its tersest form, _all without changing the signature_.
-*   Cryptographic primitives such as keys, hashes, and signatures are structured strings with a recognizable data type prefix and a standard representation. This means they are very terse, and there is no need for the variety of representation methods that create interoperability challenges in other DID methods (`publicKeyJwk` versus `publicKeyMultibase` versus other; see [section 5.2 of the DID spec](https://www.w3.org/TR/did-core/#verification-material)).
+*   **Content in CESR is self-describing and supports serialization into the binary and text domains**: That is in CESR, _a digital signature on a CESR data structure is stable no matter which underlying serialization format is used_.  In effect it supports multiple popular serialization formats like JSON, CBOR, and MsgPack with room for many more. These formats can be freely mixed and combined in a CESR stream because of the self-describing nature of these individual CESR data structures.  The practical effect is that developers get the best of both worlds: they can produce and consume data in the text domain to display and debug in a human-friendly form and they can store and transmit this data in its tersest form, _all without changing the signature on the data structures_.
+*   **Cryptographic primitives are structured into compact standard representations**: Cryptographic primitives such as keys, hashes, digests, sealed-boxes, signatures, etc... are structured strings with a recognizable data type prefix and a standard representation in the stream. This means they are very terse and there is no need for the variety of representation methods that create interoperability challenges in other DID methods (`publicKeyJwk` versus `publicKeyMultibase` versus other; see [section 5.2 of the DID spec](https://www.w3.org/TR/did-core/#verification-material)).
 
-Despite this rich set of features, KERI imposes only light dependencies on developers. The cryptography it uses is familiar and battle-hardened, exactly what one would find in standard cryptography toolkits for big numbers and elliptic curves. For example, the python implementation uses just the `pysodium`, `blake3`, and `cryptography` packages. Libraries for KERI exist in javascript, rust, and python.
+Despite this rich set of features, KERI imposes only light dependencies on developers. The cryptography it uses is familiar and battle-hardened, exactly what one would find in standard cryptography toolkits. For example, the python implementation (keripy) only depends on the `pysodium`, `blake3`, and `cryptography` python packages. Libraries for KERI exist in javascript, rust, and python.