Documentation of Version 1 asset contracts (CBOR) format#897
Documentation of Version 1 asset contracts (CBOR) format#897gwillen wants to merge 2 commits intoElementsProject:masterfrom
Conversation
|
ACK 63f7056 |
|
ACK |
| * (The field names `"precision"`, `"ticker"`, and `"entity"` are reserved for backwards compatibility, and may not be used.) | ||
| * `"name"`, a string containing ASCII characters, length 1 to 255 (inclusive) | ||
| * `"issuer_pubkey"`, a byte-string containing a secp256k1 public key in compressed form. | ||
| * `"domain"`, a domain name belonging to the issuer |
There was a problem hiding this comment.
Maybe also specify how the accompanying real-world contract can be found on this domain, with the hash of the text of this real-world contract to be used as 'contract hash' in the issuance ?
There was a problem hiding this comment.
This way wallets will be able to locate the real-world contract governing the off-chain conditions, verify that it is indeed referenced in the issuance, and display the contract to the user
There was a problem hiding this comment.
We mention the use of the 'domain' field a bit later under 'Registry rules' -- it's only used to prove the identity of the asset issuer. The use of "contract" here is not referring to a legal contract, but just to this structure with the parameters of the asset in it. (There is some discussion below of how these "contracts" are distributed.)
If the issuer wanted to add a reference to some other document, they would do that by adding another field, but it would be up to them to define the meaning of it.
There was a problem hiding this comment.
Why not define the standard way to do this, especially if there is a need to pull some file from that domain to prove the identity of the issuer ?
There was a problem hiding this comment.
and if standard way is defined, then there's no need for adding another field
doc/asset-contracts-cbor.md
Outdated
| Registry rules: | ||
| * A registry may impose additional restrictions on contracts, beyond those described above. | ||
| * In particular: The Liquid Asset Registry requires the `name`, `issuer_pubkey`, and `domain` fields to be present, and the `domain` field must be controlled by the issuer, which must be proven by the existence of a specific file served over https from that domain. | ||
| * The domain validation rule helps protect registry users against assets which are intended to spoof other assets. |
There was a problem hiding this comment.
What is the domain validation rule exactly ?
| * Some additional restrictions are imposed on the CBOR data, for security, ease of parsing, and (limited) JSON compatibility: | ||
| * The CBOR must be "well-formed" and "valid", and decoding must be done in "strict mode" if possible, as defined in RFC 7049: | ||
| * Maps MUST NOT have duplicate keys. | ||
| * Strings MUST be valid UTF-8. |
There was a problem hiding this comment.
Domain names should be ASCII, punycode etc to mitigate https://en.wikipedia.org/wiki/IDN_homograph_attack
5 participants
This document describes:
Left for another document which will come separately:
cleanly handle assets with different levels of precision (i.e., number of digits after the
decimal point)