move to v1.1.0

CODEOWNERS

@@ -2,6 +2,6 @@
 # the repo. Unless a later match takes precedence,
 # they will be requested for review when someone opens a 
 # pull request.
-*        @thehenrytsai @tplooker @csuwildcat @troyronda @OR13 @xinaxu
+*        @thehenrytsai @tplooker @csuwildcat @troyronda @OR13 @xinaxu @decentralgabe
 
 # See CODEOWNERS syntax here: https://help.github.com/articles/about-codeowners/#codeowners-syntax

docs/v1.1.0/api/content.md

@@ -0,0 +1,157 @@
+## REST API
+
+The following sections define the Sidetree resolution and operations endpoints. Please refer to the companion [Sidetree REST API](https://identity.foundation/sidetree/swagger/) specification for additional information, as well as REST API definitions for the anchoring and CAS components.
+
+### Sidetree Resolution
+
+Sidetree resolution requests to the REST API are based on the [DID Resolution HTTP(S) binding](https://w3c-ccg.github.io/did-resolution/#bindings-https).
+Resolution requests consist of a DID and MAY include DID parameters.
+As detailed in [Resolution](#resolution), the resolution request MAY include the initial state DID parameter.
+
+The server responds with the [DID Resolution Result](https://w3c-ccg.github.io/did-resolution/#did-resolution-result) composed of the DID Document and Method Metadata.
+Sidetree defines `published`, `updateCommitment`, and `recoveryCommitment` method metadata.
+   - `published` is detailed in [Published Property](#published-property).
+   - `updateCommitment` is the commitment for the next update operation as defined in [commitment schemes](https://identity.foundation/sidetree/spec/#commitment-schemes).
+   - `recoveryCommitment` is the commitment for the next recover or deactivate operation as defined in [commitment schemes](https://identity.foundation/sidetree/spec/#commitment-schemes).
+
+::: example
+```json
+{
+    "@context": "https://w3id.org/did-resolution/v1",
+    "didDocument": DID_DOCUMENT_OBJECT,
+    "didDocumentMetadata": {
+        "method": {
+            "published": boolean,
+            "updateCommitment": UPDATE_COMMITMENT,
+            "recoveryCommitment": RECOVERY_COMMITMENT
+        }
+    }
+}
+```
+:::
+
+A resolution is requested as follows:
+
+1. The client ****MUST**** send a GET to the Sidetree resolution endpoint `/identifiers/{did-with-or-without-initial-state}` under the desired REST server path.
+2. If the DID does not exist and initial state was not provided:
+   - The server ****MUST**** respond with HTTP Status Code 404.
+3. If the DID does not exist and valid initial state was provided:
+   - The server ****MUST**** respond with HTTP Status Code 200.
+   - The server ****MUST**** include the `didDocument` property, with its value set to the initial DID document that is constructed from the initial state.
+   - The server ****MUST**** include the resolution response object `didDocumentMetadata` composed of a `method` object, which includes a `published` property with value `false`.
+4. If the DID does exist and has not been deactivated:
+   - The server ****MUST**** respond with HTTP Status Code 200.
+   - The server ****MUST**** include the `didDocument` property, with its value set to the latest DID document.
+   - The server ****MUST**** include the resolution response object `didDocumentMetadata` composed of a `method` object which includes a `published` property with value `true`.
+5. If the DID does exist and has been deactivated:
+    - The server ****MUST**** respond with HTTP Status Code 200.
+    - The server ****MUST**** include the `didDocument` property, with its value set to a valid empty DID document including the populated `id` property.
+    - The server ****MUST**** include the resolution response object `didDocumentMetadata` which includes a `deactivated` property with value `true`.
+6. Otherwise, for failure, the server ****MUST**** respond with an appropriate HTTP Status Code (400, 401, 404, 500).
+
+### Sidetree Operations
+
+Sidetree operation requests to the REST API consist of a type property indicating the operation to be performed along with operation-specific properties and data.
+
+::: example
+```json
+{
+    "type": OPERATION_TYPE,
+    ...
+}
+```
+:::
+
+A valid Sidetree Operation Request is a JSON document composed as follows:
+
+1. The Operation Request ****MUST**** contain a `type` property, and its value ****MUST**** be a valid operation defined in
+[File Structure](#file-structures). The defined operations are `create`, `recover`, `deactivate`, `update`.
+2. Populate additional properties according to the appropriate subsection.
+3. The client ****MUST**** POST the Operation Request JSON document to the Sidetree operation endpoint `/operations` under the desired REST server path.
+4. The server ****MUST**** respond with HTTP status 200 when successful. Otherwise, for failure, the server ****MUST**** respond with an appropriate HTTP Status Code (400, 401, 404, 500).
+   - In the case of a successful `create` operation, the server ****MUST**** return the DID Resolution Result for the DID as is detailed in [Sidetree Resolution](#sidetree-resolution).
+
+#### Create
+
+::: example
+```json
+{
+    "type": "create",
+    "suffixData": SUFFIX_DATA_OBJECT,
+    "delta": DELTA_OBJECT
+}
+```
+:::
+
+Use the following process to generate a Sidetree create operation JSON document for the REST API, composed as follows:
+
+1. The object ****MUST**** contain a `type` property, and its value ****MUST**** be `create`.
+2. The object ****MUST**** contain a `suffixData` property, and its value must be a _Suffix Data Object_(#core-index-file-create-entry).
+3. The object ****MUST**** contain an `delta` property, and its value must be a [_Create Operation Data Object_](#create-data-object).
+
+#### Update
+
+::: example
+```json
+{
+    "type": "update",
+    "didSuffix": SUFFIX_STRING,
+    "revealValue": REVEAL_VALUE,
+    "delta": DELTA_OBJECT,
+    "signedData": JWS_SIGNED_VALUE
+}
+```
+:::
+
+Use the following process to generate a Sidetree update operation JSON document for the REST API, composed as follows:
+
+1. The object ****MUST**** contain a `type` property, and its value ****MUST**** be `update`.
+1. The object ****MUST**** contain a `didSuffix` property, and its value ****MUST**** be the [DID Suffix](#did-suffix) of the DID the operation pertains to.
+1. The object ****MUST**** contain a `revealValue` property, and its value ****MUST**** be the [reveal value](https://identity.foundation/sidetree/spec/#default-parameters) of the DID the operation pertains to.
+1. The object ****MUST**** contain an `delta` property, and its value ****MUST**** be an [_Update Operation Delta Object_](#update-data-object).
+1. The object ****MUST**** contain a `signedData` property, and its value ****MUST**** be an [IETF RFC 7515](https://tools.ietf.org/html/rfc7515) compliant JWS Compact
+Serialization of the Update operation as defined in [Provisional Index File](https://identity.foundation/sidetree/spec/#provisional-index-file).
+
+#### Recover
+
+::: example
+```json
+{
+    "type": "recover",
+    "didSuffix": SUFFIX_STRING,
+    "revealValue": REVEAL_VALUE,
+    "delta": DELTA_OBJECT,
+    "signedData": JWS_SIGNED_VALUE
+}
+```
+:::
+
+Use the following process to generate a Sidetree recovery operation JSON document for the REST API, composed as follows:
+
+1. The object ****MUST**** contain a `type` property, and its value ****MUST**** be `recover`.
+1. The object ****MUST**** contain a `didSuffix` property, and its value ****MUST**** be the [DID Suffix](#did-suffix) of the DID the operation pertains to.
+1. The object ****MUST**** contain a `revealValue` property, and its value ****MUST**** be the [reveal value](https://identity.foundation/sidetree/spec/#default-parameters) of the DID the operation pertains to.
+1. The object ****MUST**** contain an `delta` property, and its value ****MUST**** be a [_Recovery Operation Delta Object_](#recover-delta-object).
+1. The object ****MUST**** contain a `signedData` property, and its value ****MUST**** be an [IETF RFC 7515](https://tools.ietf.org/html/rfc7515) compliant JWS Compact
+Serialization of the Recovery operation as defined in [Core Index File](https://identity.foundation/sidetree/spec/#core-index-file).
+
+#### Deactivate
+
+::: example
+```json
+{
+    "type": "deactivate",
+    "didSuffix": SUFFIX_STRING,
+    "revealValue": REVEAL_VALUE,
+    "signedData": JWS_SIGNED_VALUE
+}
+```
+:::
+
+Use the following process to generate a Sidetree deactivate operation JSON document for the REST API, composed as follows:
+
+1. The object ****MUST**** contain a `type` property, and its value ****MUST**** be `deactivate`.
+1. The object ****MUST**** contain a `didSuffix` property, and its value ****MUST**** be the [DID Suffix](#did-suffix) of the DID the operation pertains to.
+1. The object ****MUST**** contain a `revealValue` property, and its value ****MUST**** be the [reveal value](https://identity.foundation/sidetree/spec/#default-parameters) of the DID the operation pertains to.
+1. The object ****MUST**** contain a `signedData` property, and its value ****MUST**** be an [IETF RFC 7515](https://tools.ietf.org/html/rfc7515) compliant JWS Compact
+Serialization of the Deactivate operation as defined in [Core Index File](https://identity.foundation/sidetree/spec/#core-index-file).

docs/v1.1.0/api/title.md

@@ -0,0 +1,28 @@
+Sidetree REST API
+==================
+
+**Specification Status:** Editor's Draft
+
+**Latest published version:**
+  [identity.foundation/sidetree/api](https://identity.foundation/sidetree/api)
+
+**Editors:**
+~ [Troy Ronda](https://www.linkedin.com/in/troyronda/) (SecureKey)
+~ [Henry Tsai](https://www.linkedin.com/in/henry-tsai-6b884014/) (Microsoft)
+
+**Contributors:**
+~ [Mudassir Ali](https://www.linkedin.com/in/mudassir-ali-4981654/) (Microsoft)
+~ [Isaac Chen](https://www.linkedin.com/in/isaac-chen-921079127/) (Microsoft)
+~ [Kyle Den Hartog](https://www.linkedin.com/in/kyledenhartog/) (Mattr)
+~ [Daniel Buchner](https://www.linkedin.com/in/dbuchner/) (Microsoft)
+~ [Orie Steele](https://www.linkedin.com/in/or13b/) (Transmute)
+
+**Participate:**
+~ [GitHub repo](https://github.com/decentralized-identity/sidetree)
+~ [File a bug](https://github.com/decentralized-identity/sidetree/issues)
+~ [Commit history](https://github.com/decentralized-identity/sidetree/commits/master)
+
+**Sidetree protocol specification:**
+  [identity.foundation/sidetree/spec](https://identity.foundation/sidetree/spec)
+
+------------------------------------

docs/v1.1.0/bitcoin.md

@@ -0,0 +1,77 @@
+# Bitcoin Blockchain Service Reference Implementation
+
+
+## Value Time Lock
+
+### Protocol parameters
+
+| Protocol parameters                  | Description                                              |
+| ------------------------------------ | ---------------------------------------------------------|
+| valueTimeLockDurationInBlocks        | The duration which a value time lock is required to have |
+
+### Configuration parameters
+* valueTimeLockUpdateEnabled
+
+This parameter controls whether the value time lock is actively being renewed and if the funds will be returned to wallet in case of `valueTimeLockAmountInBitcoins` being set to zero. When this parameter is set to `false`, parameters `valueTimeLockAmountInBitcoins`, `valueTimeLockPollPeriodInSeconds` and `valueTimeLockTransactionFeesAmountInBitcoins` will be ignored.
+
+* valueTimeLockAmountInBitcoins
+
+The desired fund locked to write larger operation batches. Set to 0 will causes existing locked fund (if exists) to be released back to wallet upon lock expiry.
+
+* valueTimeLockPollPeriodInSeconds
+
+The polling duration between checks to see if the value time lock needs to be re-locked or released back to wallet.
+
+* valueTimeLockTransactionFeesAmountInBitcoins
+
+The fund allocated for transaction fees for subsequent re-locking of the initial value time lock.
+
+> Developer's note:
+This allotted amount is locked together with value time lock for simplicity of re-lock implementation. If this allotted amount is depleted due to subsequent re-locks, the remaining locked amount will be released back to wallet, and a new lock will be created with this allotted amount added to it again.
+
+## Events
+
+### `bitcoin_databases_revert`
+Occurs every time the databases are reverted due to a bitcoin reorg.
+
+Event data:
+```json
+{
+  "blockHeight": "The block height that the databases are reverted to.",
+}
+```
+
+### `bitcoin_lock_monitor_lock_released`
+Occurs every time the lock monitor releases a value lock.
+
+Event data: none
+
+### `bitcoin_lock_monitor_lock_renewed`
+Occurs every time the lock monitor renews an existing lock.
+
+Event data: none
+
+### `bitcoin_lock_monitor_new_lock`
+Occurs every time the lock monitor creates a new lock.
+
+Event data: none
+
+### `bitcoin_lock_monitor_loop_failure`
+Occurs every time the lock monitor loop fails.
+
+Event data: none
+
+### `bitcoin_lock_monitor_loop_success`
+Occurs every time the lock monitor loop succeeds.
+
+Event data: none
+
+### `bitcoin_observing_loop_failure`
+Occurs every time the bitcoin observing loop fails.
+
+Event data: none
+
+### `bitcoin_observing_loop_success`
+Occurs every time the bitcoin observing loop succeeds.
+
+Event data: none

docs/v1.1.0/contribution-guidlines.md

@@ -0,0 +1,72 @@
+# Contribution Guidelines
+
+The following document covers the contribution guidelines for the artifacts in this repository.
+
+## Commit message format
+
+A well formed commit message communicates context about a change. A diff will tell you what changed. A well cared for
+commit log is a beautiful and useful thing.
+
+What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all
+involved. From reviews to maintenance it's a powerful tool. Understanding why something happened months or years ago
+becomes not only possible but efficient.
+
+We rely on consistent commit messages as we use
+[conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) which automatically generates
+the changelog diff based on the commit messages
+
+We enforce well formed commit messages with pre-commit hooks using [husky](https://github.com/typicode/husky).
+
+The following guidelines are based on the angular
+team's [contribution guide](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
+Checkout [commitizen](https://www.npmjs.com/package/commitizen) and [commitlint.io](https://commitlint.io/) for
+assistance in how it works.
+
+In general the commit message **MUST** be of the following form to validate
+
+```
+type(scope): subject
+```
+
+Where the `type` must be one of the following, indicating the type of change being made by the commit.
+
+* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+* **docs**: Documentation only changes
+* **feat**: A new feature
+* **fix**: A bug fix
+* **perf**: A code change that improves performance
+* **refactor**: A code change that neither fixes a bug nor adds a feature
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+* **test**: Adding missing tests or correcting existing tests
+
+The `scope` defines what is being changed, in this repository the scope **MUST** be one of the following
+
+* **spec**: Changes being made to the Sidetree specification
+* **ref-imp**: Changes being made to the Sidetree reference implementation
+
+The `subject` should be a short descriptive statement describing the nature of the change made by the commit.
+
+Full examples
+
+```
+feat(ref-imp): add fee calculation algorithm
+```
+
+or 
+
+```
+fix(spec): ambiguity around update operation terminology
+```
+
+### Breaking changes
+
+When your commit features a breaking change, the commit body should feature `BREAKING CHANGE: <description of the breaking change>` so that these are noted correctly in the resulting changelog.
+
+### Helper script
+
+A helper scripts of `commit` is included in the `package.json` to aid in making well formed commit messages, when you are ready to commit changes simply run the following and follow the prompts
+
+```
+npm run commit
+```