Initial PR for SIP1

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,22 @@
 ## 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
 ```
 
 ### 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.
-
-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:
+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, propagagted, 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. A [_Long-Form DID URI_](#long-form-did){id="long-form-did"} is the [_Short-Form DID URI_](#short-form-did) with an additional colon-separated (`:`) segment appended to the end, the value of which is 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:
 
 ```html
-did:METHOD:<did-suffix>?initial-state=<create-suffix-data-object>.<create-delta-object>
+did:METHOD:<did-suffix>:<create-suffix-data-object>.<create-delta-object>
 ```
 
-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.