Differences

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

--- cbdc:public:cbdc_omg:04_doc:90_recommend:start [2022/05/10 15:15]
nick
+++ cbdc:public:cbdc_omg:04_doc:90_recommend:start [2022/06/17 19:33] (current)
terrance
@@ Line 1: / Line 1: @@
 ====== 6.0 Recommendations ======
-[[cbdc:private:cbdc_omg:start| OMG Responses to Federal Reserve Discussion Paper]]
+|< 100% >|
+| [[cbdc:public:cbdc_omg:04_doc:start | Return to Main Document]]  |  <WRAP>
+<html><b>
+<a href="mailto:[email protected]?Subject=OMG's CBDC WG Response:
+.0 Recommendations
+">Provide Feedback</a></b>
+</html>
+</WRAP>  |
+The OMG's CBDC WG members wanted to make recommendations to the Federal Reserve for future activities in the area of a U.S. CBDC. They propose 12 different direct actions or activities. One of these activities involves the use of RDT&E funding to explore eight specific Research Development Test & Evaluation (RDT&E) topics.
 The **Object Management Group® (OMG®)**, founded in 1989, is an international not-for-profit software consortium (aka
@@ Line 7: / Line 15: @@
 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:v:vcsb | Voluntary Standards Consensus Body (VSCB)]]) that sets standards in the many areas including distributed object computing. This means the OMG organization plans, develops, establishes, or coordinates voluntary consensus standards using agreed-upon [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:p_p | Policies and Procedures (P&P)]]. The P&P provides a framework for openness and transparency to aid in balancing the interests of the Stakeholders, providing due process for disagreements, and building consensus.
-The OMG is not a financial institution, a government institution, or a provider of goods, services, or technology. The main goal of the OMG is to produce standard technical specifications for use by the national and international communities with a proven track record, see the [[cbdc:private:cbdc_omg:04_doc:04_intro:start#about_the_object_management_group_omg | Introduction]]). Based on our experience in formulating the responses to the questions posed in the **White Paper**, our members have formulated a set of recommendations to help aid the Federal Reserve to move forward with a U.S. CBDC. The OMG members are very active in 26 vertical markets, including Business, Finance, Government, Healthcare, Manufacturing, Military, Robotics, Space, and Telecoms.
+The OMG is not a financial institution, a government institution, or a provider of goods, services, or technology. The main goal of the OMG is to produce standard technical specifications for use by the national and international communities with a proven track record, see the [[cbdc:public:cbdc_omg:04_doc:04_intro:start#about_the_object_management_group_omg| Introduction]]). Based on our experience in formulating the responses to the questions posed in the **White Paper**, our members have formulated a set of recommendations to help aid the Federal Reserve to move forward with a U.S. CBDC. The OMG members are very active in 26 vertical markets, including Business, Finance, Government, Healthcare, Manufacturing, Military, Robotics, Space, and Telecoms.
-<nspages cbdc:private:cbdc_omg:04_doc:90_recommend: -tree -r -exclude -subns -pagesInNs -h1 -textNs="">
+<nspages cbdc:public:cbdc_omg:04_doc:90_recommend: -tree -r -exclude -subns -pagesInNs -h1 -textNs="">
-===== Instilling Confidence in the CBDC  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The [[https://www.omg.org/ | Object Management Group (OMG) ]] recommends the Federal Reserve uses a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) approach for future CBDC efforts. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, Design, and testing will CBDC have the stability it needs to instill confidence of the public.
-Some of the potential requirements in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] as summarized by the [[https://www.omg.org/ | Object Management Group's ]] [[cbdc:private:cbdc_omg:04_doc:12_summary:start| White Paper Analysis]] reflect the need to instill public confidence (See Table {{ref>confidence}})
-<table confidence>
-<caption>Some requirements in the White Paper that require the confidence of the public.</caption>
-^ Statement No.  ^  Page No.  ^ Statement  |
-^ B0020 ^  13  | Maintain public confidence by not requiring mechanisms, such as deposit insurance |
-^ R0003 ^  3  | **Risk** to the safety and stability of the financial system |
-^ R0004 ^  3  | **Risk** to the efficacy of monetary policy |
-^ R0005 ^  7  | New payment services could pose **Risks** to: <WRAP>
-  - financial stability
-  - payment system integrity
-  - other **Risks**
-</WRAP>|
-^ R0011 ^  11  | Increased **Risk** to consumer's vulnerability to: <WRAP>
-  - loss
-  - theft
-  - fraud
-</WRAP>|
-</table>
-===== Adopting a Model-Based Systems Engineering (MBSE) Approach  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-For more than forty years, the practice of systems engineering followed a linear path: requirements are documented
-first, followed by analysis then conceptual design—through the development life cycle. However, regardless of the
-engineering process employed—waterfall, incremental, iterative, spiral, and even sprint-based—the lack of
-integration from one phase to another in the cycle results in longer delivery times and increases costs to correct errors
-introduced at transition points.
-**Model-Based Systems Engineering (MBSE)**((
-"Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements,
-design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout
-development and later life cycle phases.” INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02), Sept 2007
-MBSE
-)) is an initiative in the systems engineering community that uses
-model-based descriptions and transformations so that work occurs concurrently. Requirements collection, analysis,
-and specifications are performed at the same time as conceptual design. MBSE is practiced across many industries
-around the globe. For example, it was used to develop the world’s largest telescopes, propulsion engines for fighter
-jets, autonomous driving cars, software solutions to include software-defined radios, and space applications (hardware and software).
-MBSE is often contrasted with a more traditional document-based approach to systems engineering, where system
-information is spread across many document-based artifacts (handwritten text documents, spreadsheets, and
-drawings). MBSE brings information together into a cohesive, integrated model of the system that:
-  - Enhances precision, consistency, and traceability;
-  - Includes behavioral analysis, system architecture, requirement traceability, performance analysis, simulation, test, etc.;
-  - Formalizes the practice of systems development through the use of models;
-  - Integrates information across discipline-specific engineering tools, including hardware and software design, analysis, simulation, and test; and
-  - Facilitates shared understanding of the system among the development team, resulting in:\\
-    * quality/productivity improvements and lower risk;
-    * rigor and precision;
-    * ongoing communications among development team and customer; and
-    * management of complexity.
-For more information on MBSE, please see:
-  * [[https://www.omg.org/intro/MBSE.pdf | MBSE Specifications at OMG]]:
-  * [[cbdc:private:cbdc_omg:8_append:60_mbse | MBSE Overview in Appendix]].
-The [[https://www.omg.org/ | Object Management Group (OMG)]] also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See [[https://www.omg.org/spec/UAF/ | OMG Unified Architecture Framework (UAF)]]:
-UAFP 1.0 supports the capability to:
-  * model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;
-  * model consistent architectures for System-of-Systems (SoS) down to lower levels of design and implementation;
-  * support the analysis, specification, design, and verification of complex systems; and
-  * improve the ability to exchange architecture information among related tools that are SysML-based and tools that are based on other standards.
-The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.
-The [[https://www.omg.org/ | Object Management Group ]] also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See [[https://www.omg.org/spec/UAF/ | OMG Unified Architecture Framework (UAF)]], it is summarized here:
-//UAF Profile (UAFP) 1.0 supports the capability to://
-  * //Model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;//
-  * //Model consistent architectures for System-of-Systems (SoS) down to lower levels of design and implementation;//
-  * //Support the analysis, specification, design, and verification of complex systems; and//
-  * //Improve the ability to exchange architecture information among related tools that are SysML based and tools that are based on other standards.//
-//The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.//
-===== Defining the Appropriate Standards or Specifications  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-===== Perform Research Development Test & Evaluation (RDT&E)  =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]]
-==== Consensus Algorithms ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-  : // Consensus algorithms are the basis of all the blockchains/DAGs. They are the most important part of the blockchain/DAG platforms. Without them(consensus algorithms) we will be left with just a dumb, immutable database.//((
-Vaibhav Saini,
-hackernoon.com,
-__ConsensusPedia: An Encyclopedia of 30+ Consensus Algorithms, A complete list/comparison of all Consensus Algorithms__,
-June 2-18,
-Accessed: 7 September 2021
-[[https://hackernoon.com/consensuspedia-an-encyclopedia-of-29-consensus-algorithms-e9c4b4b7d08f]]
-))
-The OMG members recommend the Federal Reserve invest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting any
-[[https://www.omgwiki.org/CBDC/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:consensus_algorithm | Consensus Algorithms ]] required by the CBDC since they are an essential part of any DIDO implementation such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:blockchain | Blockchain]],
-[[https://www.omgwiki.org/CBDC/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers|Distributed Ledger]],
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:directed_acyclic_graph_dag | Directed Acyclical Graphs]], etc).
-There are a few consequences to not having "the best" Consensus Algorithms for the CBDC:
-  * Loss of confidence in the Federal Reserve and the CBDC by the Stakeholders
-  * Cost of operating the CBDC
-  * Unavailability during disasters
-  * Vulnerability during Cyberattacks
-Currently, in the Cryptocurrency world, most of the Mining Operations have moved from being distributed to being centralized and operated be a few select organizations in highly centralized locations. For example,
-  : //Fundamentally, Bitcoin mining operations ad traditional data centers are similar in the basic design and operational principles. Power must be brought into the building and distributed to the requirement, air distribution systems cool the equipment, and the building provides protection from outdoor conditions and security threats.//((
-Sunbird,
-__Largest Bitcoin Mining Farms in the World__,
-Accessed: 9 May 2022,
-[[https://www.sunbirddcim.com/sites/default/files/Sunbird_InfoGraphic_Bitcoin.pdf]]
-))
-If this is true for a U.S. CBDC, then what advantage does the CBDC have over the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtp | Real-Time Payments (RTP)]] developed by the
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:ach | Automated Clearing House (ACH) Network]].
-==== Artifical Intelligence (AI) ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting Artificial Intelligence (AI) for use with and alongside a U.S. CBDC. The AI could help in detecting suspicious security and criminal activities. When combined with [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometrics | Biometrics]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometric_authentication | Biometric Authentication]].
-AI could also consider time and geospatial data to make informed decisions about the validity of a proposed transaction.
-==== Ontologies ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting glossaries, taxonomies, and ontologies used to represent the U.S. CBDC, the Intermediaries, and the needs of the Stakeholders. There already exists an OMG Ontology, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:fibo| Financial Industry Business Ontology (FIBO) ]] that probably needs to be extended or updated to handle a U.S. CBDC.
-==== Smart Contracts ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:smart_contract&s[]=smart&s[]=contracts | Smart Contracts]]. Currently, the //de facto// standard for Smart Contracts is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:ethereum |  Ethereum]] language called [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:solidity | Solidity]]. See the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:defact:ethereum:ethereum_solidity:start | Ethereum Solidity Language Specification]]. However, there are shortcomings in the language which could either be updated or replaced with a more comprehensive language and may not even be procedural in nature. For example, the graphically based [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:bpmn | Business Process Model And Notation (BPMN)]]. Another possibility would be to develop a standardized, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:pim | Platform-Independent Model]] for a Smart Contract [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programming Interface (API)]] which could have multiple [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:psm | Platform Specific Models]] developed from the PIM.
-<figure PIM_PSM>
-{{  :cbdc:private:cbdc_omg:04_doc:90_recommend:screen_shot_2022-05-09_at_3.39.27_pm.png?600  |}}
-<caption>Creating a Platform Indepenent Model (PIM) and transforming it into various Platform Specific Models (PSMs)</caption>
-</figure>
-==== Complex Data Model ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-The OMG members recommend the Federal Reserve use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation (RDT&E) Funding ]] in developing and perfecting how to model data on a blockchain and especially what data to store on a blockchain.
-TBD TBD TBD
-Most of the data models underlying cryptocurrencies are pretty simple. Generally, it's a balance.
-The OMG members recommend There needs to be a comprehensive study of what needs to be stored in addition to the simple balance, especially if the "ledger" is going to try and prevent criminal activity and protect privacy. It also means that there will most likely be a confederation of blockchains and the need to link these together with the blockchains. some examples of concepts not covered in the existing models are association and composition. However, this extra data comes at a cost.
-==== Understanding Gas ====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-  : //A gas is worth of 0.00000005 ETH and if you planning to store data or let’s say a 256-bit word it will cost you 20,000 gas. A kilobyte is thus 640k gas or 0.032 ETH or 16.70 USD as per the current rate of Ethereum which is $528.3 Dollar.//
-  : //Now calculate the price of storing one GB of data on a blockchain decentralized ledger and blow your mind away with an enormous amount that will come up. As per the current price of Ethereum, 1MB of data will cost you up approx. 17,100 USD. Calculate the price you will need to pay to store 1GB data of data on the blockchain.//
-  Though the facts mentioned above is only true for public Ethereum blockchain while the case can be totally different if we focus on a few private or permissioned blockchain. One will, after reading the solution, definitely conceive the idea of using blockchain as the secured database is far way better than using the traditional database.
-  * 1 Gwei equals 0.000000001 ETH)
-  * median gas price (28 Gwei)
-  * USD/ETH exchange rate ($295/ETH)
-|< 100% 20% >|
-^  Task  ^     Gas required         ^  Cost (ETH)  ^  Cost (USD)  ^  Ops per ETH  ^  Ops per USD  ^  Ops per Block  ^  Blocks to complete OP  |
-^ Add or subtract two integers	    |            3 | 0.000000009 |  0.000002655 | 11111111.11       | 37664.78343 | 1566666.667 | 0.0000006382978230 |
-^ Add two Integers, 1 Million times |      3000000 | 0.09        | 26.550000000 |        11.1111111 | 0.037664783 | 1.566666667 | 0.638297872 |
-|< 100% 20% >|
-^  Task  ^     Gas required         ^  Cost (ETH)  ^  Cost (USD)  ^  Ops per ETH  ^  Ops per USD  ^  Ops per Block  ^  Blocks to complete OP  |
-^ Save a 256-bit word to Storage      |   20000 | 0.0006 | 0.171 | 1666.666667 | 5.649711751 | 243 | 0.004255319 |
-^ Save 1MB to Storage (31250 256-bit words) | 625000000 | 18.75 | 5531.25 | 0.053333333 | 0.000180791 | 0.00752 | 132.9787234 |
-^ Save 1GB to Storage (31250 256-bit words) | 6250000000000 | 18750 | 5531250 | 0.00005333333 | 0.00000018079 | 0.00000752 | 132978.7234 |
-===== Security Baked-in not Bolted-on =====
-[[cbdc:private:cbdc_omg:04_doc:90_recommend:start| Return to Top of Recommendations]]
-Also see the answers to:
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:start]]
-     * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q07:start]]
-     * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q07:start#lack_of_reporting_and_oversight | Lack of Reporting and Oversight]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:dsn:q18:start]]
-   * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q02:start]]
-Cryptocurrency skirts near the edges of illegal, illicit, or shady interactions and transactions. The Chainalysis Team recently published their 2021 findings((
-__DeFi Takes on a Bigger Role in Money Laundering, But a Small Group of Centralized Services Still Dominate__,
-Chainalysis Team,
-January 2022,
-Accessed: 4 April 2022,
-[[https://blog.chainalysis.com/reports/2022-crypto-crime-report-preview-cryptocurrency-money-laundering/]]
-)) which highlights some security issues associated with the unregulated or poorly regulated Cryptocurrency realm. The following is an excerpt from the report:
-  : //Overall, going by the amount of cryptocurrency sent from illicit addresses to addresses hosted by services, **cybercriminals laundered $8.6 billion worth of cryptocurrency in 2021**.//
-  : //That represents a **30% increase in money laundering activity over 2020**, though such an increase is unsurprising given the significant growth of both legitimate and illicit cryptocurrency activity in 2021. We also need to note that these numbers only account for funds derived from “cryptocurrency-native” crime, meaning cybercriminal activity such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dark_web | Dark Web]] market sales or ransomware attacks, in which profits are virtually always derived in cryptocurrency rather than fiat currency. It’s more difficult to measure how much fiat currency derived from offline crime — traditional drug trafficking, for example — is converted into cryptocurrency to be laundered. However, we know anecdotally this is happening, and later in this section provide a case study showing an example of it.//
-Therefore, security needs to be "baked into" the CBDC from the onset and can not be an afterthought; however, it is hard to balance the tightrope between the need for **Privacy** and the need for **Security**. This difficulty in achieving a balance has been captured in Desirement **''R0014''**:
-^ R0014 ^ Risk of not achieving an appropriate balance between safeguarding the privacy rights of consumers and affording the transparency necessary to deter criminal activity |
-It appears that the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start | Digital Cash Model]] is less vulnerable than the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start | Digital Account Model]]. The use of Stablecoins could help with maintaining the value of CBDC, but would not add any security.
-Regardless of which model ([[cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start| Digital Accounts]], [[cbdc:private:cbdc_omg:04_doc:15_common:30_stablecoins:start| Stablecoins]], [[cbdc:private:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash]]) is used for the CBDC, the [[https://www.omg.org/ | Object Management Group ]] recommends that the Federal Reserve consider Seurity of the system from the earliest phases of the U.S. CBDC. This means having the Non-Functional requirement of Security be well defined and formal.
-One way to accomplish this is through the use of a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) to model all aspects of the CBDC before it is built. Since the requirements for the security of the system are a moving, ever-changing target, this does not mean that every security issue must be fully understood or specified before work can begin. It means that at every step, the Security question needs to be raised. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, and Design will the CBDC have the stability it needs to instill confidence in the public.
-During system development, MBSE and UAF models of the system are used along with Use Scenarios and Use Cases to flush out potential problems. This means thinking about all aspects of the State of Data throughout its lifecycle. The OMG DIDO-RA has detailed discussions of the various states of data and how it relates to a distributed system.
-Figure {{ref>DataStateFigure}} graphically represents the different Data States within a system. Most systems are now able to handle Data-in-Motion and Data-at-Rest issues but have traditionally relied on physical security to protect Data-in-Use.
-<figure DataStateFigure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
-<caption>The various States of Data</caption>
-</figure>
-Table {{ref>dataStateTable}} provides a quick overview of the various data states. These data states are described in detail in the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:start | OMG DIDO-RA]].
-<table dataStateTable>
-<caption>Data can exist in the following different states</caption>
-|< 100% 20% >|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_at_rest   | Data-at-Rest ]]  |<WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dataatrest | Data-at-Rest ]] refers to all data in computer storage. It excludes data while it is moving across or within a network, and it excludes data that is temporarily residing in computer memory.
-</WRAP>|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_motion | Data-in-Motion]] | <WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion | Data-in-Motion ]], also referred to as **Data in Transit** or **Data in Flight**, is a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:digital_asset | Digital Asset]] transmitted between locations (i.e., between computers or computer components). Data-In-Motion also describes data within [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:computermemory | Random Access Memory (RAM)]].
-</WRAP>|
-^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_use    | Data-in-Use]]    |<WRAP>
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_use | Data-in-Use ]] covers data being processed (i.e., updated, processed, erased, accessed or read) by a system. Data-In-Use is not passively stored, but is actively moving through parts of a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:computerplaform | Computing Platform]] (i.e., [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cpu | Central Processing Unit (CPU)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dram | Dynamic Random Access Memory (DRAM),]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bus | Data Bus]], etc.). **Data-In-Use** is one of three states of digital data -- the other states are [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_at_rest | Data-at-Rest]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_motion | Data-in-Motion]].
-</WRAP>|
-</table>
-<table>
-<caption>White Paper Desirements related to disruption and security</caption>
-^ Statement No.  ^  Page No.  ^ Statement  |
-^ B0004 ^  2  | Protect consumer privacy|
-^ B0005 ^  2  | Protect against criminal activity|
-^ B0053 ^  20  | Provide resiliency to threats to existing payment services—including: <WRAP>
-  - operational disruptions
-  - cybersecurity risks
-</WRAP>|
-^ R0011 ^  11  | Increased **Risk** to consumer's vulnerability to: <WRAP>
-  - loss
-  - theft
-  - fraud
-</WRAP>|
-^ D0015 ^  20  | **Design** should include any dedicated infrastructure required to provide a resilience to threats such as operational disruptions and cybersecurity risks |
-^ D0016 ^  20  | **Design** should include offline capabilities to help with operational resilience of the payment system  |
-^ D0017 ^  20  | **Design** should include digital payments in areas suffering from large disruption, such as natural disasters |
-</table>
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

OMG Central Bank Digital Currency (OMG-CBDC) Working Group (WG) Wiki

User Tools

Site Tools

Differences

Page Tools