Merge pull request #1 from trustoverip/convert-ms-did-x509-spec

Convert Microsoft did:x509 spec to Spec-Up format

package.json

@@ -55,6 +55,7 @@
     "merge-stream": "2.0.0",
     "pkg-dir": "4.2.0",
     "prismjs": ">=1.24.0",
+    "spec-up": "^0.10.6",
     "yargs": "16.2.0"
   }
 }

spec/did_resolution_options.md

@@ -0,0 +1,13 @@
+## DID resolution options
+
+This DID method introduces a new DID resolution option called `x509chain`:
+
+Name: `x509chain`
+
+Value type: string
+
+The value is constructed as follows:
+
+1. Encode each certificate `C` that is part of the chain as the string `b64url(DER(C))`.
+
+2. Concatenate the resulting strings in order, separated by comma `","`.

spec/example.md

@@ -0,0 +1,5 @@
+## Example
+
+`did:x509:0:sha256:WE4P5dd8DnLHSkyHaIjhp4udlkF9LqoKwCvu9gl38jk::subject:C:US:ST:California:O:My%20Organisation`
+
+In this example, the identifier pins to a certificate authority using the SHA-256 certificate hash and uses the `subject` policy to express criteria which a leaf certificate's subject must fulfill. This identifier will match any certificate chains with matching leaf certificate subject fields and a matching intermediate or root CA certificate.

spec/header.md

@@ -1,6 +1,6 @@
 ## Status of This Memo
 
-This document contains a template specification for `ToIP`!.
+This document contains a working draft for the specification for the `did:x509` DID method.
 
 Information about the current status of this document, any errata,
 and how to provide feedback on it, may be obtained at
@@ -19,7 +19,6 @@ and the designated source code license, the terms of the OWF Contributor License
 
 These terms are inherited from the Technical Stack Working Group at the Trust over IP Foundation. [Working Group Charter](https://trustoverip.org/wp-content/uploads/TSWG-2-Charter-Revision.pdf)
 
-
 ## Terms of Use
 
 These materials are made available under and are subject to the [OWF CLA 1.0 - Copyright & Patent license](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owf-contributor-license-agreement-1-0-copyright-and-patent). Any source code is made available under the [Apache 2.0 license](https://www.apache.org/licenses/LICENSE-2.0.txt).
@@ -28,12 +27,14 @@ THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, establis
 IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ## RFC 2119
+
 The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and to ensure maximal efficiency in operation. IETF has been operating since the advent of the Internet using a Request for Comments (RFC) to convey “current best practice” to those organizations seeking its guidance for conformance purposes.
 
-The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements.  ToIP has adapted the IETF RFC 2119 for use in the <name of this document>, and therefore its applicable use in ToIP-compliant governance frameworks.
+The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements. ToIP has adapted the IETF RFC 2119 for use in the `did:x509` Method Specification, and therefore its applicable use in ToIP-compliant governance frameworks.
 
 The RFC 2119 keyword definitions and interpretation have been adopted. Those users who follow these guidelines SHOULD incorporate the following phrase near the beginning of their document:
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
 
 RFC 2119 defines these keywords as follows: