Merge pull request #88 from edeykholt/main

Mostly grammar fixes, some clarifications, and a few "TODO:"s

spec/abstract.md

@@ -14,7 +14,7 @@ The `did:webs` method does not need blockchains for trust. However, its use of
 KERI allows for the referencing of arbitrary blockchains as an extra, optional
 publication mechanism. This offers an interoperability bridge from (or between)
 blockchain ecosystems. Also, without directly supporting environments where the
-web is not practical (e.g., IOT, Lo-Ra, BlueTooth, NFC), the method builds on a
+web is not practical (e.g., IOT, Lo-Ra, Bluetooth, NFC), the method builds on a
 foundation that fully supports those environments, making future interop of
 identifiers between web and non-web a manageable step.
 

spec/core.md

@@ -73,7 +73,7 @@ practices to preserve good hygiene.
 
 However, the authenticity of data is
 guaranteed by the DID value itself, in conjunction with a digitally signed
-data structure called a [[ref: KERI event stream]], which includes the
+data structure called a [[ref: KERI event stream]], which includes for a given AID its 
 [[ref: key event log]] ([[ref: KEL]]) and [[ref: transaction event log]] ([[ref: TEL]]). These trust
 mechanisms — the integrity checks built into the DID value, and the workings of
 the [[ref: KERI event stream]] — are defined by [[ref: KERI]].
@@ -95,7 +95,7 @@ The location of the [[ref: KERI event stream]] is determined by transforming the
 A GET on that URL MUST return the [[ref: KERI event stream]] for the AID in the `did:webs` identifier.
 The [[ref: KERI event stream]] MUST be CESR-formatted (media type of application/cesr) and the KERI events must be verifiable using the KERI rules.
 
-The following are some `did:webs` DIDs and their corresponding DID document and [[ref: KERI event stream]]
+The following are some example `did:webs` DIDs and their corresponding DID document and [[ref: KERI event stream]]
 URLs, based on the examples from the [DID Web Specification](https://github.com/w3c-ccg/did-method-web/), but with the (faked) AID
 `12124313423525` added:
 
@@ -119,7 +119,7 @@ specification. This specification assumes a working knowledge of the concepts
 there. The inclusion of KERI in `did:webs` enables a number of capabilities for
 securing a `did:webs` identifier, including multi-signature support and the
 creation of [[ref: pre-rotated]] keys to prevent loss of control of the identifier if the
-current private key is compromised.
+current private key were to be compromised.
 
 A target system cannot forge or tamper with data protected by KERI, and if it
 deliberately serves an outdated copy, the duplicity is often detectable. Thus,
@@ -166,14 +166,14 @@ as KERI witnesses and watchers.
 ### Handling Web Redirection
 
 A `did:webs` is intended to be a "stable" (long-lasting) identifier that can be
-put into documents, such as verifiable credentials, that are intended to be
+put into documents such as verifiable credentials, and that are intended to be
 useful for a very long time -- generations. However, the web is not a very
 stable place, and documents are moved around and copied frequently. When two or
 more companies merge, often the web presence of some of the merged entities
 "disappears". It may not be possible to retain a permanent `did:webs` web
 location.
 
-When a `did:webs` moves, its AID does not change. The same [[ref: KERI event stream]] is used to verify
+When a `did:webs` is updated for another location, its AID does not change. The same [[ref: KERI event stream]] is used to verify
 the DID document. Were the AID to change, it would be an altogether new DID,
 unconnected to the first DID. So if a resolver can find a newly named DID that
 uses the same AID, and the [[ref: KERI event stream]] verifies the DID, then they have resolved the

spec/diddocuments.md

@@ -100,7 +100,7 @@ as a `did:webs` DID and as a `did:keri` DID as well.  Finally, the same AID may
 multiple domains at the same time and they should be considered the same DID since the AID portion
 of the DIDs are the same.
 
-For each synonymous DID defined above (we need a way in KERI to declare other domains it is being
+For each synonymous DID defined above (TODO: we need a way in KERI to declare other domains it is being
 served under, unless this is an implementation specific detail) an entry in the `alsoKnownAs` array
 in the DID document should be created.  For the DID
 `did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M` the following `alsoKnownAs`
@@ -122,12 +122,12 @@ KERI identifiers express public signing keys as Composable Event Streaming Repre
 determine the cryptographic algorithm used to generate the key pair.  For each key listed in the array value of the `k` field
 a corresponding verification method will be generated in the DID document.  The 'type' property  in the verification method for each
 public key will be determined by the algorithm used to generate the public key.  At the time of this writing, KERI currently
-supports public key generation for Ed25519, Secp256k1 and Secp256r1 keys, however the protocol allows for others to be added at any time.
+supports public key generation for Ed25519, Secp256k1 and Secp256r1 keys, and the protocol allows for others to be added at any time.
 We must define the subset of public key algorithms for KERI AIDs that this specification will accept, so we can define mappings to existing verification method types as registered in the DID Specification Registries.  As KERI evolves with more algorithms, new verification method types must be registered in the DID Specification Registries and added to this specification.
 
 The `id` property of the verification method must be a relative DID URL and use the KERI key CESR value as the value of the fragment component, e.g., `"id": "#<identifier>"`.
 
-The `controller` property of the verification method must be the value of the `id` property of DID document. (Does the method spec need to specify this?)
+The `controller` property of the verification method must be the value of the `id` property of DID document. (TODO: Does the method spec need to specify this?)
 
 For example, the key `DFkI8OSUd9fnmdDM7wz9o6GT_pJIvw1K_S21AKZg4VwK` in the DID document for the AID `EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2` becomes:
 

spec/keri.md

@@ -47,7 +47,7 @@ Unlike a blockchain with a distributed consensus mechanism, witnesses do not coo
 
 ### 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
 

spec/privacy_considerations.md

@@ -4,7 +4,7 @@ For privacy considerations related to web infrastructure, see [`did:web` privacy
 Below we discuss privacy considerations related the KERI infrastructure.
 
 ### Surveillance
-In KERI, A robust witness network along with consistent witness rotation provides protection from monitoring and association of
+In KERI, a robust witness network along with consistent witness rotation provides protection from monitoring and association of
 an individual's activity inside a KERI network.
 
 ### Stored Data Compromise