CIP-0014 | Adjust preamble and structure w.r.t CIP-0001 (cardano-foundation#658)

* first draft remediation of CIP-0014

* spelled NA instead of standard N/A

Author: rphair

CIP-0014/README.md

@@ -1,28 +1,31 @@
 ---
 CIP: 14
 Title: User-Facing Asset Fingerprint 
-Authors: Matthias Benkort <[email protected]>, Rodney Lorrimar <[email protected]>
-Comments-Summary: A common format for displaying a user-facing identifier for assets.
-Comments-URI: https://github.com/cardano-foundation/CIPs/wiki/Comments:CIP-0014
 Status: Active
-Type: Standards
+Category: Tokens
+Authors:
+  - Matthias Benkort <[email protected]>
+  - Rodney Lorrimar <[email protected]>
+Implementors: N/A
+Discussions:
+  - https://github.com/cardano-foundation/CIPs/pull/64
 Created: 2020-02-01
 License: CC-BY-4.0
 ---
 
-# Abstract
+## Abstract
 
 This specification defines a user-facing asset fingerprint as a bech32-encoded blake2b-160 digest of the concatenation of the policy id and the asset name.
 
-# Motivation
+## Motivation: why is this CIP necessary?
 
 The Mary era of Cardano introduces the support for native assets. On the blockchain, native assets are uniquely identified by both their so-called policy id and asset name. Neither the policy id nor the asset name are intended to be human-readable data. 
 
 On the one hand, the policy id is a hash digest of either a monetary script or a Plutus script. On the other hand, the asset name is an arbitrary bytestring of up to 32 bytes (which does not necessarily decode to a valid UTF-8 sequence). In addition, it is possible for an asset to have an empty asset name, or, for assets to have identical asset names under different policies. 
 
 Because assets are manipulated in several user-facing features on desktop and via hardware applications, it is useful to come up with a short(er) and human-readable identifier for assets that user can recognize and refer to when talking about assets. We call such an identifier an _asset fingerprint_.
 
-# Specification
+## Specification
 
 We define the asset fingerprint in pseudo-code as:
 
@@ -39,35 +42,13 @@ assetFingerprint := encodeBech32
 
 where `|` designates the concatenation of two byte strings. The `digest-length` is given in _bytes_ (so, 160 bits).
 
-# Rationale
+### Reference Implementation
 
-## Design choices
-
-- The asset fingerprint needs to be _somewhat unique_ (although collisions are plausible, see next section) and refer to a particular asset. It must therefore include both the policy id and the asset name.
-
-- Using a hash gives us asset id of a same deterministic length which is short enough to display reasonably well on small screens.
-
-- We use bech32 as a user-facing encoding since it is both user-friendly and quite common within the Cardano eco-system (e.g. addresses, pool ids, keys).
-
-## Security Considerations
-
-- With a 160-bit digest, an attacker needs at least 2^80 operations to find a collision. Although 2^80 operations is relatively low (it remains expansive but doable for an attacker), it 
-  is considered safe within the context of an asset fingerprint as a mean of _user verification_ within a particular wallet. An attacker may obtain advantage if users can be persuaded 
-  that a certain asset is in reality another (which implies to find a collision, and make both assets at the reach of the user). 
-
-- We recommend however that in addition to the asset fingerprint, applications also show whenever possible a visual checksum calculated from the policy id and the asset name as specified in [CIP-YET-TO-COME](). Such generated images, which are designed to be unique and easy to distinguish, in combination with a readable asset fingerprint gives strong verification means to end users. 
-
-# Backwards Compatibility
-
-N/A
-
-# Reference Implementation
-
-## Javascript
+#### Javascript
 
 [cip14-js](https://www.npmjs.com/package/@emurgo/cip14-js)
 
-## Haskell (GHC >= 8.6.5)
+#### Haskell (GHC >= 8.6.5)
 
 <details>
   <summary>Language Extensions</summary>
@@ -130,7 +111,7 @@ mkAssetFingerprint (PolicyId policyId) (AssetName assetName)
     hrp = [humanReadablePart|asset|]
 ```
 
-## Test Vectors
+### Test Vectors
 
 > :information_source: `policy_id` and `asset_name` are hereby base16-encoded; their raw, decoded, versions should be used when computing the fingerprint.
 
@@ -168,6 +149,35 @@ mkAssetFingerprint (PolicyId policyId) (AssetName assetName)
   asset_fingerprint: asset1pkpwyknlvul7az0xx8czhl60pyel45rpje4z8w
 ```
 
-# Copyright
+## Rationale: how does this CIP achieve its goals?
+
+### Design choices
+
+- The asset fingerprint needs to be _somewhat unique_ (although collisions are plausible, see next section) and refer to a particular asset. It must therefore include both the policy id and the asset name.
+
+- Using a hash gives us asset id of a same deterministic length which is short enough to display reasonably well on small screens.
+
+- We use bech32 as a user-facing encoding since it is both user-friendly and quite common within the Cardano eco-system (e.g. addresses, pool ids, keys).
+
+### Security Considerations
+
+- With a 160-bit digest, an attacker needs at least 2^80 operations to find a collision. Although 2^80 operations is relatively low (it remains expansive but doable for an attacker), it 
+  is considered safe within the context of an asset fingerprint as a mean of _user verification_ within a particular wallet. An attacker may obtain advantage if users can be persuaded 
+  that a certain asset is in reality another (which implies to find a collision, and make both assets at the reach of the user). 
+
+- We recommend however that in addition to the asset fingerprint, applications also show whenever possible a visual checksum calculated from the policy id and the asset name as specified in [CIP-YET-TO-COME](). Such generated images, which are designed to be unique and easy to distinguish, in combination with a readable asset fingerprint gives strong verification means to end users. 
+
+## Path to Active
+
+### Acceptance Criteria
+
+- [x] Asset fingerprints as described have been universally adopted in: wallets, blockchain explorers, query layers, token minting utilities, NFT specifications, and CLI tools.
+
+### Implementation Plan
+
+- [x] Reference implementations available in both Javascript and Haskell.
+- [x] Public presentation with confirmed interest in adopting this standard in advance of Mary ledger era.
+
+## Copyright
 
-CC-BY-4.0
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).