User Tools

Site Tools


requirements:use-cases:use-case-trade-finance-letter-of-credit

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
requirements:use-cases:use-case-trade-finance-letter-of-credit [2016/11/01 14:25]
Jeremy Sevareid Migrated from legacy github wiki
requirements:use-cases:use-case-trade-finance-letter-of-credit [2016/11/01 20:23] (current)
Jeremy Sevareid Amended - Fixed migration formatting. Deleted - boilerplate sections, replacing with TBD markings.
Line 1: Line 1:
-FIXME 
- 
 ===== Use Case - Trade Finance Letter of Credit ===== ===== Use Case - Trade Finance Letter of Credit =====
  
Line 16: Line 14:
  
 ==== User Stories ==== ==== User Stories ====
-As a Seller I want to be paid as soon as I have delivered the products according to the terms and conditions in the LoC. During the LoC contract agreement stage I want to make sure that the terms and conditions are acceptable to me.+As a SellerI want to be paid as soon as I have delivered the products according to the terms and conditions in the LoC. During the LoC contract agreement stage I want to make sure that the terms and conditions are acceptable to me.
  
-As a Buyer I want to pay only for products that have been delivered according to the terms and conditions specified in the LoC. During the contract agreement stage I want to make sure that the terms and conditions are acceptable to me.+As a BuyerI want to pay only for products that have been delivered according to the terms and conditions specified in the LoC. During the contract agreement stage I want to make sure that the terms and conditions are acceptable to me.
  
-As an issuing banker I want to be able to verify that the seller has performed delivery according to the LoC before paying the seller.+As an issuing bankerI want to be able to verify that the seller has performed delivery according to the LoC before paying the seller.
  
-As an advising banker I want to be able to advise the seller regarding the LoC received from the Issuing bank during the contract agreement, and conveys the delivery documents from the Seller to the Issuing bank, and accepts payment from the issuing bank for the Seller.+As an advising bankerI want to be able to advise the seller regarding the LoC received from the Issuing bank during the contract agreement, and conveys the delivery documents from the Seller to the Issuing bank, and accepts payment from the issuing bank for the Seller.
  
-Usage Scenario Examples+=== Usage Scenario Examples ​===
  
 1. The Buyer finds a Seller/​Supplier and executes a sales contract or pro forma invoice. The Buyer and Seller agree on the terms and conditions to be included in the LoC 1. The Buyer finds a Seller/​Supplier and executes a sales contract or pro forma invoice. The Buyer and Seller agree on the terms and conditions to be included in the LoC
Line 44: Line 42:
 9. The issuing bank collects payment from Buyer, and provides the delivery documents to the Buyer. 9. The issuing bank collects payment from Buyer, and provides the delivery documents to the Buyer.
  
-Problem Definition+==== Problem Definition ​====
  
 The process today is highly manual and requires the reconciliation between several independent records on each entity involved - Buyer, Issuing Bank, Advising Bank, Seller. The Blockchain could be the shared source of truth and work-flow engine to automate the process and provide cryptographic proof if actions and performance. The process today is highly manual and requires the reconciliation between several independent records on each entity involved - Buyer, Issuing Bank, Advising Bank, Seller. The Blockchain could be the shared source of truth and work-flow engine to automate the process and provide cryptographic proof if actions and performance.
  
-Related User Stories or Problems +==== Related User Stories or Problems ​====
- +
- "​NONE"​. +
- +
-Opportunity/​Justification +
- +
-This section is mandatory. +
- +
-Use this section to give opportunity details that support why pursuing these user stories would help address key barriers to adoption or operation. +
- +
-Some examples of information that might be included here are applicable market segments, workloads, user bases, etc. and any associated data. +
- +
-Requirements +
- +
-This section is mandatory, but only top level sections need to be answered. +
- +
-It is useful to specify requirements that should be considered but may not be apparent through the user story and usage examples. This information will help the developers be aware of any additional known constraints that need to be met for adoption of the newly implemented features/​functionality. Precise specifications of the requirements make a developer'​s job much easier, so when in doubt, consult a technical expert. +
- +
-Use this section to define the functions that must be available or any specific technical requirements that exist in order to successfully support your use case. If there are requirements that are external to this group, note them as such. Please always add a comprehensible description to ensure that people understand your need. If technical requirements go beyond the scope of a user story (i.e. cryptographic signatures with very unique requirements),​ feel free to add references or supplemental technical material. +
- +
-Explain why these requirements are needed for your user story: +
- +
-* General Requirements +
-* Correctness Requirements +
-* Privacy Requirements +
-* Hardware Requirements +
-* Others Use Cases with Similar Requirements +
-General Requirements:​ +
- +
-Blockchain Specifics - Amount/type of block chains needed, or interaction with legacy block chains. +
- +
-Federation Size - Number of parties involved in a single blockchain federation. +
- +
-Legal Association — legal and structural requirements of federation members, and how the enter (and exit) the federation (for instance entrance bonds or exit costs may be required to avoid sybil attacks). +
- +
-Transaction Group Size - Number of parties involved in a blockchain transaction. +
- +
-Connectivity / transaction frequency (bandwidth / latency). +
- +
-Transaction ordering - UTXO / transaction stream. +
- +
-Correctness Requirements:​ +
- +
-Requirement for external or trusted third-party?​ +
- +
-Dispute resolution (internal to federation, say by vote or penalty, or external, say by assocation, mediation, arbitration or law). +
- +
-Bad Actor / Sybil Attack Resistance level? Mitigation approaches? Policy embodied in code or by contract law? +
- +
-Audit requirements - (for instance, with HD keys you need the private deterministic chain code in order to successfully audit a public key account). +
- +
-Consensus protocol: Proof of Work, Proof of Stake, Open Federation, provable BCP, Stellar Consensus, RAFT/​PAXOS. +
- +
-Proof of Publication/​Existence Timestamp: (how precise? to multiple blockchains?​). +
- +
-Finality - how long does it take for a transaction to become irreversible?​ This could have both time and probability of irreversiblity constraints. +
- +
-Privacy requirements:​ +
- +
-Consensus Makers - permissionless,​ censorship resistent, permissioned,​ open federation, closed federation. +
- +
-Delegation - Do participants need to delegate permissions/​secrets,​ and if so, how? +
- +
-Identification - Permissioned to Pseudoanonymous,​ non-correlatable (selective disclosure?​),​ groups. +
- +
-Signatures: simple signatures, single signature multiple authentication,​ multi-signatures,​ threshold signatures, smart signatures (signatures with various functional signing properties ranging from basic to extremely complex), accountability (know who voted, or to not know who voted for a threshold). +
- +
-Revocation or Short-term authentication?​ +
- +
-Separate signature vs encryption keys? +
- +
-Wallet requirements?​ Hardware only, etc. +
- +
-Hierarchical Deterministic Keys? +
- +
-Blockchain publication (public, only auditors, blinded, private). +
- +
-Separate signatures and transactions?​ +
- +
-Privacy domains (aka who needs to see or not see signatures, contracts, transactions,​ consensus). +
- +
-Biometric Privacy - Are there extra security requirements for particularly sensitive information?​ +
- +
-Level of cryptographic computation (from low to high) to support the above correctness and privacy requirements:​ basic cca encryption, blinded, multi-party computation,​ homomorphic encryption/​signatures,​ functional encryption/​signatures with desired level of functionality and other properties. +
- +
-Level of general "smart contract"​ computation requirements to support the above correctness and privacy requirements:​ none, signature verification only, smart signatures (and/or), bitcoin script level, intermediary level, Turing complete language. +
- +
-Hardware Requirements +
- +
-Biometric Authentication +
- +
-Embedded Execution / Trusted Hardware? Ring 0, 1, 2? +
- +
-Others Use Cases with Similar Requirements +
- +
-External References +
- +
-This section is mandatory, but may be NONE. +
- +
-Please use this section to add references for standards or well-defined mechanisms. In particular, if any of your requirements specifically call for the implementation of a standard or protocol or other well-defined mechanism, use this section to list them. +
- +
-Additionally,​ if your use case needs non-standard consensus mechanisms or cryptographic tools, please include technical material here, or references to technical material (i.e. a link to an eprint paper with security proofs). Remember, the burden of proof for security or consensus of non-standard mechanisms will be placed upon the proposer rather than the evaluator of the proposal, so be verbose here if necessary. +
- +
-Rejected User Stories / Usage Scenarios +
- +
-This is optional.+
  
-Please fill out this section after a User Story has been submitted as a cross project spec to highlight any user stories deemed out of scope of the relevant cross project spec.+TBD
  
-Glossary/Appendices+==== Opportunity/Justification ====
  
-This section is optional.+TBD
  
-It is highly suggested that you define any terms, abbreviations that are not commonly used in order to ensure that your user story is understood properly.+==== Requirements ====
  
-Provide a list of acronyms, their expansions, and what they actually mean in general language here. Define any terms that are specific to your problem domain. If there are devices, appliances, or software stacks that you expect to interact with Hyperledger,​ list them here.+TBD
  
-Remember: The better you communicate your user story, the more likely it is to be considered by the project teams and the product working group.+==== External References ==== 
 +TBD
  
-Examples:+==== Glossary/​Appendices ====
  
-**reST** reStructuredText is a simple markup language +TBD
-**TLA** Three-Letter Abbreviation is an abbreviation consisting of three letters +
-**xyz** Another example abbreviation+
requirements/use-cases/use-case-trade-finance-letter-of-credit.txt · Last modified: 2016/11/01 20:23 by Jeremy Sevareid