merge SMP/DCP replacements with ausdigital-foo/1 references

APIs/swagger.json

@@ -0,0 +1,9 @@
+{
+  "swagger" : "2.0",
+  "info" : {
+    "version" : "1.0",
+    "title" : "Transaction Access Point (TAP)",
+    "description" : "The \"Transaction Access Point\" (TAP) is an open standard specification defining RESTful exchange of e-business documents between ledger systems. See http://ausdigital.org/ for more information."
+  },
+  "paths" : { }
+}

docs/index.md

@@ -1,4 +1,4 @@
-**[Back to Ausdigital.org](http://ausdigital.org/)**
+**[Back to AusDigital.org](http://ausdigital.org/)**
 
 # 1/TAP
 
@@ -8,6 +8,18 @@
  * Editor: Chris Gough
  * Contributors: Steve Capell
 
+##Glossary:
+
+phrase | Definition
+------------ | -------------
+ausdigital-tap/2 | Version 2 of the [AusDigtial](http://ausdigital.org) [TAP](http://ausdigital-tap.readthedocs.io/) specification
+ausdigital-tapgw/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [TAPGW](http://ausdigital-tap-gw.readthedocs.io/) specification
+ausdigital-bill/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [BILL](http://ausdigital-bill.readthedocs.io/) specification
+ausdigital-dcl/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [DCL](http://ausdigital-dcl.readthedocs.io/) specification
+ausdigital-dcp/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [DCP](http://ausdigital-dcp.readthedocs.io/) specification
+ausdigital-nry/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [NRY](http://ausdigital-nry.readthedocs.io/) specification
+ausdigital-idp/1 | Version 1 of the [AusDigtial](http://ausdigital.org) [IDP](http://ausdigital-idp.readthedocs.io/) specification
+
 This document describes a protocol for exchanging formal documents (such as invoices)
 between businesses. TAP is a secure, decentralised, peer to peer architecture where gateways
 are optional and minimally trusted.

docs/introduction.md

@@ -8,45 +8,45 @@ document exchange.
 A TAP might be provided by a commercial ledger service, or maintained as part of an
 independent business system. 
 
-The TAP specification has two parts. The main part (TAP) defines the protocol all peers
+The TAP specification has two parts. The main part (ausdigital-tap/2) defines the protocol all peers
 must follow (and interfaces they must provide) to send and receive business documents. The
-second part is an optional gateway specification (TAPGW), which defines a client-server
+second part is an optional gateway specification (ausdigital-tapgw/1), which defines a client-server
 protocol for trusted business system components (e.g. ledger services) to interact with independent TAP service providers in a generic way.
 
 
 ## Dependencies
 
 The messages sent between TAPs carry semantic payloads. Currently, these include
-[billing-semantics](https://ausdigital-bill.readthedocs.io/).
+ausdigital-bill/1.
 That specification is maintained independently in the
 [https://github.com/ausdigital/ausdigital-bill](https://github.com/ausdigital/ausdigital-bill)
 repository. Future semantic payloads may be supported without change to the protocol.
 
 All TAPs depend on the following Services:
 
- * [Digital Capability locator (DCL)](http://ausdigital-dcl.readthedocs.io/)
- * [Digital Capability Publisher (DCP)](http://ausdigital-dcp.readthedocs.io/)
- * [Notary (NTY)](http://ausdigital-ntry.readthedocs.io)
+ * ausdigital-dcl/1 
+ * ausdigital-dcp/1 
+ * ausdigital-nry/1 
 
 TAPGW providers also depend on the
-[Identity Provider (IDP)](http://iausdigital-idp.readthedocs.io/). TAPs do not need to
+ausdigital-idp/1. TAPs do not need to
 authenticate when they interact with each other, due to use of well known cryprograpic keys
 and service endpoint addresses.
 
 
 ## TAP Protocol Overview
 
-In this protocol, a Transaction Access Point (TAP) is a business system component that sends and recieves business messages. The TAP Protocol describes how one TAP sends the message, and how the other TAP responds when a message is received.
+In this protocol, a Transaction Access Point (TAP) is a business system component that sends and receives business messages. The TAP Protocol describes how one TAP sends the message, and how the other TAP responds when a message is received.
 
-The message is sent to the recieving TAP using HTTP POST operation, with a `Content-Type: multipart/form-data` body. This body contains two parts, `message` and `signature`.
+The message is sent to the receiving TAP using HTTP POST operation, with a `Content-Type: multipart/form-data` body. This body contains two parts, `message` and `signature`.
 
-The `message` part is a mixture of cleartext metadata (used by TAPs) and encyphered payload (used by trusted business system components). The cleartext metadata does not contain sensitive business information, wheras access to the business-sensitive information within the payload is not necessary for participating in the TAP protocol.
+The `message` part is a mixture of cleartext metadata (used by TAPs) and enciphered payload (used by trusted business system components). The cleartext metadata does not contain sensitive business information, whereas access to the business-sensitive information within the payload is not necessary for participating in the TAP protocol.
 
 The `signature` part is created by a business system component trusted by the sender (with access to the sender's private key material). The signature can be used as a unique identifier of the message contents (e.g. transmitted document id).
 
 ![Illustration of POST body](./tap_overview_post.png "Business document sent to TAP")
 
-Receiving TAPs may also use the signature as a filter (messages with invalid signatures MAY be dropped by recieving TAPs, rather than delivered). This allows TAPs to buffer trusted components from anonymous denial of service attacks.
+Receiving TAPs may also use the signature as a filter (messages with invalid signatures MAY be dropped by receiving TAPs, rather than delivered). This allows TAPs to buffer trusted components from anonymous denial of service attacks.
 
 When a valid message is received, the TAP issues an HTTP 200 status and returns a response body with `Content-Type: text/json`, containing a HATEOS-style list of callback URLs.
 

docs/tap_details.md

@@ -9,11 +9,11 @@ The TAP Protocol is a very simple REST API. One business sends a message directl
 
 ## Sending a business message
 
-Pre-requsites:
+Pre-requisites:
 
  * Sender knows their own business identity, and has access to their own private key.
  * Sender knows the recipient business identity (e.g. ABN).
- * Sender knows recipient Digital Capability Publisher (DCP) address, which can be discovered from business identity using Digital Capability Lookup (DCL).
+ * Sender knows recipient Digital Capability Publisher (DCP) address, which can be discovered from business identity using ausdigital-dcl/1.
  * Sender knows appropriate TAP endpoint address for the intended message type (discovered via DCP lookup).
  * Sender knows appropriate recipient public key (discovered via DCP lookup).
  * The sender has a valid cleartext (not encrypted) business document to send (e.g. an invoice), encoding the appropriate business semantics (e.g. UBL2.0) in an appropriate format (e.g. json).
@@ -79,7 +79,7 @@ The message does not contain plaintext of the business message (signed or otherw
 
 The cyphertext is created using public key cryptography, using the appropriate public key for the recipient business endpoint, and the appropriate private key of the sender. The public parts of these keypairs are discoverable using the appropriate DCP for each business identifier URNs, which is discoverable using the global DCL. Public keys MUST be published in ASCII-Armoured form in the DCP.
 
-Use of mature and extensively scrutenised cryptography implementations is strongly encouraged. The following examples use GnuPG, anthough any compliant RFC4880 imlpementation could be used in an equivalent way.
+Use of mature and extensively scrutinised cryptography implementations is strongly encouraged. The following examples use GnuPG, although any compliant RFC4880 implementation could be used in an equivalent way.
 
 Assuming the recipient's public key is not already in the sender's GnuPG keyring, but is in the current working directory as `recipient.gpg`, it can be added to the sender's GnuPG keyring like this:
 
@@ -117,7 +117,7 @@ This will create a file `cyphertext.gpg` in the current working directory, which
 
 ### Compose Message
 
-The `message` part is a mixture of cleartext metadata (used by TAPs) and encyphered payload (used by trusted business system components). The cleartext metadata does not contain sensitive business information, wheras access to the business-sensitive information within the payload is not necessary for participating in the TAP protocol.
+The `message` part is a mixture of cleartext metadata (used by TAPs) and enciphered payload (used by trusted business system components). The cleartext metadata does not contain sensitive business information, whereas access to the business-sensitive information within the payload is not necessary for participating in the TAP protocol.
 
 The message part does not need to be in any kind of canonical form. It MUST be a valid json document.
 
@@ -186,7 +186,7 @@ Layered on top of HTTP Protocol:
  * MAY explicitly declare `Content-Transfer-Encoding: base64`
  * MUST NOT rely on additional TAP-related information in HTTP headers, such as message or conversation identifiers.
 
-The message is sent to the recieving TAP using HTTP POST operation. The posted body contains two parts, named `message` and `signature`.
+The message is sent to the receiving TAP using HTTP POST operation. The posted body contains two parts, named `message` and `signature`.
 
 Assuming the current working directory contains the message (as message.json) and signature (as message.sig), the following curl command will post the message to the recipient TAP (replace `<TAP_URL>` with HTTPS URL discovered from the Service Metadata Publisher).
 
@@ -207,4 +207,4 @@ TODO:
  * example response.
  * explain callback URLs
  * explain callback semantic URLs
- * define error responses.
+ * define error responses.