rewriting attestaion.md (#16)

* rewriting attestaion.md - will remove dita later

* push the file that has error to be discussed in dita group

* Workaround issue dita-ot/dita-ot#3078 which prevents SHORTDESC to have a link in it

* splitting original attestation.dita into smaller files.

src/Bootstrap.dita

@@ -18,7 +18,7 @@
         </p>
 	<section><title>Coverage and limitation of Bootstrap Library</title>
         <p>Bootstrap Library provides support most TokenScript functions, like <xref
-                href="Card.dita"/>, <xref href="Attestation.dita"/> and <xref
+		href="Card.dita"/>, <xref href="concept/Attestation.md" format="mdita"/> and <xref
                 href="TokenNegotiation.dita"/>. However, it can't replace the TokenScript support in
             the user-agents, because it is deployed on the website as JavaScript library, it can't
             fully support the tokenscript features <xref href="TIPS.dita"/>. For example, if an

src/Documents.ditamap

@@ -19,7 +19,7 @@
             <topicref href="ActivityCard.dita"/>
         </topicref>
         <topicref href="DataObjects.dita"/>
-        <topicref href="Attestation.dita"/>
+	<topicref href="concept/Attestation.md" format="mdita"/>
         <topicref href="TokenScript-Syntax.dita"/>
         <topicref href="concept/MagicLink.md" format="mdita"/>
 

src/TokenScript.dita

@@ -113,7 +113,7 @@
             <p dir="ltr">TokenScript enables token issuers to leave the restrictions of smart
                 contracts behind. It allows to add a lot of information, even image files or API
                 lookups to a token, and design a set of business rules and interaction logics for
-                it, including <xref href="Attestation.dita">attestations</xref> and structured
+                it, including <xref href="concept/Attestation.md" format="mdita">attestations</xref> and structured
                 interactions with other tokens. </p>
             <p dir="ltr">Moreover, with TokenScript token issuers can easily and securely update the
                 token rules.</p>

src/concept/Attestation.md

@@ -0,0 +1,36 @@
+# Attestation
+
+An attestation is a cryptographically attested message, by an attestor stating someone have something. 
+
+It's a few lines long and often is delivered through a [MagicLink](MagicLink.md).
+
+Note that an attestation is produced by a trusted attestor. It is not a trustless technology. See [Attestation vs Proof](../faq/attestation_vs_authorisation_vs_proof.md).
+
+There are two types of attestations: token issued as attestations (token attestation for short), and identifier attestations.
+
+## Token Attestation
+
+Token attestations are tokens issued by sending the recipient an attestation. As long as the recipient has the attestation, he is able to interact with smart contracts as if he has a token in a token contract.
+
+An example of such token is the DevCon 2022 ticket.
+
+The advantage is that a token is never minted, and can be used as if it is minted. However, it is not transferable in that form, instead, when transferring, a token contract has to burn the attestation and allocate it to the new recipient, and the new recipient will hold the token as a normal smart contract token (not attestation token).
+
+Tokens that can be issued as attestation are non-fungible.
+
+## Identifier Attestation
+
+Identifier attestations are issued by attestors who verifies an Ethereum key holder also owns an identifier. A typical identifier is a web2 identifier such as
+
+- Email address
+- Twitter handle
+- Facebook ID
+- Github handle
+
+Use-cases of Identifier Attestations are:
+
+- To be used as a dependency for other tokens. For example, when DevCon 2022 ticket is issued, they are issued on user's identifier (email address). To use the DevCon ticket, a user has to acquire an email address attestation.
+- To be used to attest a transaction as from an identified user. For example, in AutographNFT, a person who add an autograph on an NFT must provide a twitter ID attestation, therefore attesting the autograph is from the owner of that ID.
+
+More use-cases can be found in [Attestation Usecases](../usecases/Attestation.md)
+

src/concept/MagicLink.md

@@ -10,7 +10,7 @@ Typical usecases of a MagicLink:
 
 ## Pass an attestation to a user
 
-A MagicLink contains an encoded [attestation](../Attestation.dita). The recipient of such a link can save this attestation in her wallet, or, if the wallet doesn't have specific storage for attestation, a fallback website is provided to store it in the browser local storage for this website.
+A MagicLink contains an encoded [attestation](Attestation.md). The recipient of such a link can save this attestation in her wallet, or, if the wallet doesn't have specific storage for attestation, a fallback website is provided to store it in the browser local storage for this website.
 
 ## Redeem a token
 

src/faq/TS_vs_Contract_Metadata.dita

@@ -19,7 +19,7 @@
                 and what are these interfaces. They only need to care about the functionalities
                 provided by the token.</p>
             <p>It's also possible to define a token without referring to any smart contract (0
-                contracts). Such TokenScript is only possible with <xref href="../Attestation.dita"
+		    contracts). Such TokenScript is only possible with <xref href="../concept/Attestation.md" format="mdita"
                 />.</p>
       </section>
     </body>

src/faq/attestation_vs_authorisation_vs_proof.md

@@ -0,0 +1,25 @@
+# Attestation vs Authorisation vs Proof
+
+Sometimes the word "attestation" is used interchangeably with "proof", and sometimes it's mixed with "authorisation".
+
+In TokenScript we consistently differentiate them:
+
+- An attestation is signed from a trusted attestor, such as a token issuer or attestation.id (an identifier attestation issuer).
+- An authorisation is signed from the token holder (often, the user).
+- A proof is trustless. It does not have an attestor and doesn't depend on trust towards an attestor or the token holder.
+
+Take a look at the following paragraph from sismo.io blog:
+
+> Sismo issues badges (non-transferable NFTs) to your public Ethereum profiles (ENS names). **They are Zero-Knowledge (ZK) attestations of facts imported from your other accounts** (Ethereum accounts as well as twitter or github).
+
+If the text were written in consistent with TokenScript set of terminologies, the highlighted part should be
+
+"They are Zero-Knowledge (ZK) *proofs* of facts imported from your other accounts."
+
+This is because the "attestation" produced in Sismo can be independently verified from outside of Sismo system, hence it doesn't require implied trust towards an attestor.
+
+## Examples consistent with TokenScript
+
+- DevCon tickets are token attestations issued to ticket holders.
+- If you own a car, and you sign a machine-recognisable message that allows a friend to drive the car, that message is an authorisation.
+- If you use zero-knowlege to convince a website that you own an APE, by referring to a Merkle root generated from all APE owners' addresses and proving you own one of the keys, that is a proof.

src/reusable/AttestationFormat.md

@@ -0,0 +1,12 @@
+## Attestation Format
+
+An attestation is a signed [dataObject](../DataObjects.dita). The dataObject can contain any information, including public and private information. It can be signed by an Ethereum entity and attested to a token.
+
+Attestations are non-transferable, but transferability can be achieved by attesting to another attestation.
+
+Attestations can be fully expressed by an URI for easy and cross-compatible usage. This allows to create [MagicLinks](../concept/MagicLink.md) which contain an attestation.
+
+The attestation format takes close inspiration from the X.509 certificate specification, RFC-5280, but makes several fields optional, adds a few new ones and changes some formats.
+
+There is still much work to be done. For example, we need a format that can do partial attestation by using Merkle Tree, or even zero-knowledge proof of attestation.
+

src/usecases/Attestation.md

@@ -0,0 +1,18 @@
+# Attestation Usecases
+
+A standardized attestation format has an enormous potential to smoothly integrate identity and other claims into the web and to streamline a wide range of processes, like signing up for an exchange, registering a bank account, verifying as an accredited investor for an Security Token Offer or renting a car.
+
+For example, you could create a smart contract for an ICO which requires that participants provide an attestation to be an accredited investor. This can be issued from a qualified attestor who can attest to the investor's capability. A wallet can use the attestation for any ICO in the future.
+
+Another example would be a car token. When you have the token in your wallet, you can have the option to start an insurance process which will create an insurance attestation connected to the car token. When the wallet has the attestation, TokenScript can unlock the option to take lend the car on a car sharing platform.
+
+There can also be attestations for a real life fact. For example, a smart contract may allow a blockchain payment to be redeemed on the condition that a specific job is attested as well done. Such a job can be, for example, a car painting job, identified by the job id in the corresponding Smart Contract.
+
+An identifier attestation can also be connected to an Ethereum entity like the holder of a key pair. This allows tokens use-cases such as
+
+- To be used as holders for other tokens. For example, when DevCon 2022 ticket is issued, they are issued on user's identifier (email address). To use the DevCon ticket, a user has to acquire an email address attestation.
+- To be used in a Cheque - sending tokens by email address, and later the user who has an email address identifier attestation can redeem it. The underlying smart contract will check the validity of such attestations. [Cheque protocol](../ChequeProtocol.dita) makes heavy use of attestations in such a way.
+
+- To provide dependency for other attestations. Since [Attestation can be chained](../AttestationChained.dita).
+
+TokenScript supports the integration of attestation processes, triggered by an action card directly in the wallet. You can integrate an attestation circuit into the life cycle of a token.

src/usecases/TokenAttestation.md

@@ -0,0 +1,12 @@
+# Token as Attestation vs Token in smart contract
+
+Attestation and smart contract token are related concepts: Both of them require the user to have a private key.
+
+In some use cases attestations and token are interchangeable: For example, a FIFA ticket can be either an attestation or a blockchain token. When it is an attestation, it attests the key-holder's right to enter the venue. When it is a blockchain token, it serves the same purpose, and also might be transferable within the Smart Contract rules.
+
+That reveals the first difference: an attestation isn't transferable, and a token's transferability depends on the smart contract. 
+
+The second difference is that attestations are private: They are not stored on the blockchain unless used.
+
+Some attestations carry private information. In this case, the private parts are replaced using cryptographic hide, and when they are used, a proof is generated to be written to the blockchain in an [Attested Transaction](../AttestedTransaction.dita). 
+