Initial PR for SIP1

.github/workflows/deploy-spec.yml

@@ -1,4 +1,5 @@
-name: Deploy Spec
+
+name: render-specs
 
 on:
   push:
@@ -17,11 +18,13 @@ jobs:
       - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
         run: |
           npm install
-          npm run spec
+          node -e "require('spec-up')({ nowatch: true })"
+          rm -rf node_modules
 
-      - name: Deploy 🚀
-        uses: JamesIves/github-pages-deploy-action@releases/v3
+      - name: Deploy
+        uses: peaceiris/actions-gh-pages@d38d8b3
         with:
-          ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
-          BRANCH: gh-pages # The branch the action should deploy to.
-          FOLDER: www # The folder the action should deploy.
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./www
+          allow_empty_commit: true
+          force_orphan: true

docs/spec/common-functions.md

@@ -25,7 +25,7 @@ let HashingOutput = Base64URL( Multihash(DATA, 'sha2-256') );
 The following steps define the [commitment scheme](#commitment-scheme) for generating a [public key commitment](#public-key-commitment) from a public key.
 
 1. Encode the public key into the form of a valid [JWK](https://tools.ietf.org/html/rfc7517).
-2. Canonicalize the [JWK](https://tools.ietf.org/html/rfc7517) encoded public key using the [JSON Canonicalization Scheme](https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17).
-3. Apply the defined [HASH_ALGORITHM](#hash-algorithm) to the canonicalized public key to produce the [public key commitment](#public-key-commitment).
+2. Canonicalize the [JWK](https://tools.ietf.org/html/rfc7517) encoded public key using the implementation's [`JSON_CANONICALIZATION_SCHEME`](#json-canonicalization-scheme).
+3. Use the implementation's [HASH_PROTOCOL](#hash-protocol) to the hash the canonicalized public key, then hash the resulting hash value again using the implementation's [HASH_PROTOCOL](#hash-protocol) to produce the [public key commitment](#public-key-commitment).
 
 Implementers ****MUST NOT**** re-use public keys across different commitment invocations.

docs/spec/did-uri.md

@@ -1,24 +1,98 @@
 ## DID URI Composition
 
-DID Methods based on the Sidetree protocol all share the same identifier format. The unique identifier segment of a Sidetree-based DID, known as the [DID Suffix](#did-suffix), is derived by using the [Hashing Process](#hashing-process) to generate a hash value from the decoded [_Create Operation Suffix Data Object_](#create-suffix-data-object). The [DID Suffix](#did-suffix) is cryptographically bound to the initial PKI state of the DID, which means Sidetree DIDs are _self-certifying_. As a result, a person or entity who creates a Sidetree-based DID knows their unique identifier at the moment of generation, and it is cryptographic secured for instant use (for more on the instant use capabilities of Sidetree DIDs, see [Unpublished DID Resolution](#unpublished-did-resolution)).
+DID Methods based on the Sidetree protocol all share the same identifier format. The unique identifier segment of a Sidetree-based DID, known as the [DID Suffix](#did-suffix), is derived by using the [Hashing Process](#hashing-process) to generate a hash value from the canonicalized [_Create Operation Suffix Data Object_](#create-suffix-data-object). The [DID Suffix](#did-suffix) is cryptographically bound to the initial PKI state of the DID, which means Sidetree DIDs are _self-certifying_. As a result, a person or entity who creates a Sidetree-based DID knows their unique identifier at the moment of generation, and it is cryptographic secured for instant use (for more on the instant use capabilities of Sidetree DIDs, see [Unpublished DID Resolution](#unpublished-did-resolution)).
 
-To generate the [_Short-Form DID URI_](#short-form-did){id="short-form-did"} of a Sidetree DID, use the [Hashing Process](#hashing-process) to generate a hash of the decoded [_Create Operation Suffix Data Object_](#create-suffix-data-object). The following is an example of a resulting colon (`:`) separated DID URI composed of the URI scheme (`did:`), Method identifier (`sidetree:`), and unique identifier string (`EiBJz4...`):
+To generate the [_Short-Form DID URI_](#short-form-did){id="short-form-did"} of a Sidetree DID, use the [Hashing Process](#hashing-process) to generate a hash of the canonicalized [_Create Operation Suffix Data Object_](#create-suffix-data-object). The following is an example of a resulting colon (`:`) separated DID URI composed of the URI scheme (`did:`), Method identifier (`sidetree:`), and unique identifier string (`EiBJz4...`):
 
-```css
-did:sidetree:EiBJz4qd3Lvof3boqBQgzhMDYXWQ_wZs67jGiAhFCiQFjw
+Format of Short-form DID URI:
+
+```html
+did:METHOD:<did-suffix>
+```
+
+Example of Short-Form DID URI:
+
+```javascript
+did:sidetree:EiDahaOGH-liLLdDtTxEAdc8i-cfCz-WUcQdRJheMVNn3A
 ```
 
 ### Long-Form DID URIs
 
-DID URI strings may include additional values that are used in resolution and other activities. The standard way to pass these values are through _DID URL Parameters_, as defined by the [W3C Decentralized Identifiers](https://w3c.github.io/did-core/) specification.
+In many DID Methods, there is a period of time (which may be indefinite) 
+between the generation of a DID and the DID operation being anchored, 
+propagated, and processed in the underlying distributed ledger/storage 
+network. In order to account for this, Sidetree introduces an equivalent 
+variant of Sidetree-based DIDs that is _self-certifying_ and _self-resolving_, 
+known as the [_Long-Form DID URI_](#long-form-did){id="long-form-did"}. 
+The [_Long-Form DID URI_](#long-form-did) variant of Sidetree-based DIDs 
+enables DIDs to be immediately resolvable after generation by including 
+the DID's initial state data within the [_Long-Form DID URI_](#long-form-did) 
+itself. Sidetree [_Long-Form DID URIs_](#long-form-did){id="long-form-did"} 
+are the [_Short-Form DID URI_](#short-form-did) with an additional 
+colon-separated (`:`) segment appended to the end. The value of this final 
+URI segment is a canonicalized JSON data payload composed of the 
+[_Create Operation Suffix_](#create-suffix-data-object) data and the 
+[_Create Operation Delta_](#create-delta-object) data, encoded 
+via the implementation's [`DATA_ENCODING_SCHEME`](#data-encoding-scheme). 
+The [_Long-Form DID URI_](#long-form-did) data payload segment ****must not**** 
+exceed 1 kilobyte in size.
 
-Many DID Methods require a period of time (which may be indefinite) between the generation of a DID and the DID being anchored/propagated in the underlying ledger system, and other layers for which propagation delays may apply. Sidetree introduces the `initial-state` _DID URL Parameter_ to enable resolution of unpropagated and unpublished DIDs. To use a Sidetree-based DID immediately after generation, the controller ****MUST**** include the `initial-state` _DID URL Parameter_ in the DID URI string, with the value being a string composed of the [_Create Operation Suffix Data Object_](#create-suffix-data-object) and the [_Create Operation Delta Object_](#create-delta-object), separated by a period (`.`), as follows:
+Long-form DID JSON data payload:
+
+```json
+{
+  "delta": {
+    "patches": [
+      {
+        "action": "replace",
+        "document": {
+          "public_keys": [
+            {
+              "id": "anySigningKeyId",
+              "jwk": {
+                "crv": "secp256k1",
+                "kty": "EC",
+                "x": "H61vqAm_-TC3OrFSqPrEfSfg422NR8QHPqr0mLx64DM",
+                "y": "s0WnWY87JriBjbyoY3FdUmifK7JJRLR65GtPthXeyuc"
+              },
+              "purpose": [
+                "auth"
+              ],
+              "type": "EcdsaSecp256k1VerificationKey2019"
+            }
+          ],
+          "service_endpoints": [
+            {
+              "endpoint": "http://any.endpoint",
+              "id": "anyServiceEndpointId",
+              "type": "anyType"
+            }
+          ]
+        }
+      }
+    ],
+    "update_commitment": "EiBMWE2JFaFipPdthcFiQek-SXTMi5IWIFXAN8hKFCyLJw"
+  },
+  "suffix_data": {
+    "delta_hash": "EiBP6gAOxx3YOL8PZPZG3medFgdqWSDayVX3u1W2f-IPEQ",
+    "recovery_commitment": "EiBg8oqvU0Zq_H5BoqmWf0IrhetQ91wXc5fDPpIjB9wW5w"
+  }
+}
+```
+
+Format of Long-Form DID URI:
 
 ```html
-did:METHOD:<did-suffix>?initial-state=<create-suffix-data-object>.<create-delta-object>
+did:METHOD:<did-suffix>:<long-form-suffix-data>
+```
+
+Example of Long-Form DID URI:
+
+```javascript
+did:sidetree:EiDahaOGH-liLLdDtTxEAdc8i-cfCz-WUcQdRJheMVNn3A:eyJkZWx0YSI6eyJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoiYW55U2lnbmluZ0tleUlkIiwiandrIjp7ImNydiI6InNlY3AyNTZrMSIsImt0eSI6IkVDIiwieCI6Ikg2MXZxQW1fLVRDM09yRlNxUHJFZlNmZzQyMk5SOFFIUHFyMG1MeDY0RE0iLCJ5IjoiczBXbldZODdKcmlCamJ5b1kzRmRVbWlmSzdKSlJMUjY1R3RQdGhYZXl1YyJ9LCJwdXJwb3NlIjpbImF1dGgiXSwidHlwZSI6IkVjZHNhU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOSJ9XSwic2VydmljZV9lbmRwb2ludHMiOlt7ImVuZHBvaW50IjoiaHR0cDovL2FueS5lbmRwb2ludCIsImlkIjoiYW55U2VydmljZUVuZHBvaW50SWQiLCJ0eXBlIjoiYW55VHlwZSJ9XX19XSwidXBkYXRlX2NvbW1pdG1lbnQiOiJFaUJNV0UySkZhRmlwUGR0aGNGaVFlay1TWFRNaTVJV0lGWEFOOGhLRkN5TEp3In0sInN1ZmZpeF9kYXRhIjp7ImRlbHRhX2hhc2giOiJFaUJQNmdBT3h4M1lPTDhQWlBaRzNtZWRGZ2RxV1NEYXlWWDN1MVcyZi1JUEVRIiwicmVjb3ZlcnlfY29tbWl0bWVudCI6IkVpQmc4b3F2VTBacV9INUJvcW1XZjBJcmhldFE5MXdYYzVmRFBwSWpCOXdXNXcifX0
 ```
 
-This _DID URL Parameter_ mechanism of conveying the initial _self-certifying_ state of a DID, known as the [_Long-Form DID URI_](#long-form-did){id="long-form-did"} supports the following features and usage patterns:
+The [_Long-Form DID URI_](#long-form-did) variant of Sidetree-based DIDs supports the following features and usage patterns:
 
 - Resolving the DID Documents of unpublished DIDs.
 - Authenticating with unpublished DIDs.