Differences

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

--- cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start [2022/05/16 18:21]
nick ↷ Page moved from cbdc:public:04_doc:20_comments:brp:q13:sb_02:start to cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start
+++ cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start [2022/06/17 19:15] (current)
terrance
@@ Line 1: / Line 1: @@
 ====== 2. What operational or cyber risks might be unavoidable? ======
-[[cbdc:public:04_doc:20_comments:brp:q13:start| Return to Question 13]]
+|< 100% >|
+| [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start| Return to Question 13]]  |  <WRAP>
+<html><b>
+<a href="mailto:[email protected]?Subject=OMG's CBDC WG Response:
+.2. What operational or cyber risks might be unavoidable?
+">Provide Feedback</a></b>
+</html>
+</WRAP>  |
 ===== Overview =====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-The biggest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | Risks]] to the CBDC are related to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology(IT)]] infrastructure for the CBDC and the need to ensure the CBDC meets the quality expectations of the U.S. Federal Reserve and the public. For example, the White Paper Desirements
+The biggest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | Risks]] to the CBDC is related to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology(IT)]] infrastructure for the CBDC and the need to ensure the CBDC meets the quality expectations of the U.S. Federal Reserve and the public. For example, the White Paper Desirements
   * **''B0020''** is about establishing maintaining public confidence as a priority
@@ Line 12: / Line 19: @@
   * **''R0011''** is concerned about loss, theft, and fraud
-These are unique problems to The Federal Reserve or to U.S. CBDC. These problems have been addressed by standards aimed at minimizing risk to projects heavily dependent on Software:
+These are unique problems for The Federal Reserve or to U.S. CBDC. These problems have been addressed by standards aimed at minimizing risk to projects heavily dependent on Software:
 See the the OMG DIDO-RA section on:
@@ Line 19: / Line 26: @@
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:2_tech_views:1_core:2_oss  | Open Source Paradigm]]
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:2_tech_views:1_core:4_assure | Assurance]]
+==== Specification versus Standards ====
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+The difference between [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:specification | Specification ]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:standard | Standard]] is a specification is an explicit set of requirements to be satisfied by a material, product, or service. A Standard is a principle or example or measure used for comparison.
+A [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:specification | Specification ]] are statements detailing the requirements of a system or product that **''should''** or **''must''** be satisfied depending on the regulatory or contractual context. The Specification includes work products such as the definition of Protocols, Application Programming Interfaces (API), or the definition of processes. A [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:standard | Standard]] is a specification established by institutions such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sdo | Standards Developing Organization (SDO)]] or a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:v:vcsb | Voluntary Standards Consensus Body (VSCB)]]. Standards can be classified as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech | Technical]] or //[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:defact | de facto]]// Standards.
 ==== ISO, IEC, IEEE Standards ====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-The purpose of ISO/IEC 25000 is to provide a general overview of SQuaRE contents, common reference models and definitions, as well as, the relationship among the documents and allowing users of the Guide to gain a good understanding of and how to use this series of standards. It also contains an explanation of the transition process between the old ISO/IEC 9126 and the newer ISO/IEC 14598 series and SQuaRE.
+The purpose of ISO/IEC 25000 is to provide a general overview of SQuaRE contents, common reference models, and definitions, as well as, the relationship among the documents, and allow users of the Guide to gain a good understanding of how to use this series of standards. It also contains an explanation of the transition process between the old ISO/IEC 9126 and the newer ISO/IEC 14598 series and SQuaRE.
 <figure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:qualitycharacteristicmeasures.png?700  |}}
+{{  cbdc:04_doc:20_comments:brp:q13:sb_02:qualitycharacteristicmeasures.png?700  |}}
 <caption>Quality Characteristics and Measures Specifications</caption>
 </figure>
@@ Line 48: / Line 62: @@
 ==== Object Management Group (OMG) Standards and Consortium for Information & Software Quality (CISQ) ====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-The Consortium for Information & Software Quality (CISQ) develops international standards to automate the measurement of software from source code. Industry needs standard, low-cost, automated measures for evaluating software size and structural quality that can be used to control the quality, cost, and risk of software produced internally or by third parties.
+The Consortium for Information & Software Quality (CISQ) develops international standards to automate the measurement of software from source code. The industry needs standard, low-cost, automated measures for evaluating software size and structural quality that can be used to control the quality, cost, and risk of software produced internally or by third parties.
-Automation is critical because manual review is infeasible for large multi‐layer, multi‐language, multi‐platform systems. Additionally, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:devops |DevOps]] greatly speeds up the deployment of applications, some changing on a daily or even hourly basis, which may result in unintended vulnerabilities without review.
+Automation is critical because the manual review is infeasible for large multi‐layer, multi‐language, multi‐platform systems. Additionally, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:devops |DevOps]] greatly speeds up the deployment of applications, some changing on a daily or even hourly basis, which may result in unintended vulnerabilities without review.
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:acsmm                        | OMG: Automated Source Code CISQ Maintainability Measure (ASCMM) ]]
@@ Line 67: / Line 81: @@
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:cmmn                         | OMG: Case Management Model and Notation (CMMN) ]]
-The Structured Assurance Case Metamodel (SACM) specification defines a metamodel for representing structured assurance cases. An Assurance Case is a set of auditable claims, arguments, and evidence created to support the claim that a defined system/service will satisfy the particular requirements. An Assurance Case is a document that facilitates information exchange between various system stakeholder such as suppliers and acquirers, and between the operator and regulator, where the knowledge related to the safety and security of the system is communicated in a clear and defendable way. Each assurance case should communicate the scope of the system, the operational context, the claims, the safety and/or security arguments, along with the corresponding evidence.
+The Structured Assurance Case Metamodel (SACM) specification defines a metamodel for representing structured assurance cases. An Assurance Case is a set of auditable claims, arguments, and evidence created to support the claim that a defined system/service will satisfy the particular requirements. An Assurance Case is a document that facilitates information exchange between various system stakeholders such as suppliers and acquirers, and between the operator and regulator, where the knowledge related to the safety and security of the system is communicated in a clear and defendable way. Each assurance case should communicate the scope of the system, the operational context, the claims, the safety and/or security arguments, along with the corresponding evidence.
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sacm                         | OMG: Structured Assurance Case Metamodel (SACM) ]]
-The Test Information Interchange Format (TestIF) goal is to achieve a specification that defines the format for the exchange of test information among tools, applications, and systems that utilize it. The term “test information” is deliberately vague, because it includes the concepts of tests (test cases), test results, test scripts, test procedures, and other items that are normally documented as part of a software test effort. The long term goal is to standardize the exchange of all test related artifacts produced or consumed as part of the testing process,
+The Test Information Interchange Format (TestIF) goal is to achieve a specification that defines the format for the exchange of test information among tools, applications, and systems that utilize it. The term “test information” is deliberately vague, because it includes the concepts of tests (test cases), test results, test scripts, test procedures, and other items that are normally documented as part of a software test effort. The long term goal is to standardize the exchange of all test-related artifacts produced or consumed as part of the testing process,
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:testif                       | OMG: Test Information Interchange Format (TestIF)]]
 ==== State of Data ====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
 Data can exist in many states depending on how it is being used. The risks and concerns about Data in each of its different states are also important. Often, the primary focus for understanding data is to concentrate on [[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 ]]. Even though data tends to remain relatively static, it can change over time. In the past, there was little concern for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion | Data-in-Motion ]], which can have serious effects on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:ram | Reliability, Maintainability, and Availability (RAM)]], as well as, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security | Securability]] and can leave a system vulnerable to breaches. With the advent of HTTPS, these vulnerabilities are mitigated. The latest issue has become the need to secure [[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]]. A recent WhatsApp data breach((
@@ Line 90: / Line 104: @@
 <figure DataStateFigure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
+{{  cbdc:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
 <caption>The various States of Data</caption>
 </figure>
@@ Line 111: / Line 125: @@
 ===== Examples =====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-Some "desirements" in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | Money and Payments: The U.S. Dollar in the Age of Digital Transformation]] **White Paper** and relating to **Operational or Cyber Risks** are summarized in the [[cbdc:public:04_doc:12_summary:start| White Paper Analysis]] done by the [[https://www.omg.org/ | Object Management Group ]] and listed in Table {{ref>opCyberRiskReq}}.
+Some "desirements" in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | Money and Payments: The U.S. Dollar in the Age of Digital Transformation]] **White Paper** and relating to **Operational or Cyber Risks** are summarized in the [[cbdc:public:cbdc_omg:04_doc:12_summary:start| White Paper Analysis]] done by the [[https://www.omg.org/ | Object Management Group's ]] CBDC WG and listed in Table {{ref>opCyberRiskReq}}.
 <table opCyberRiskReq>
@@ Line 126: / Line 140: @@
 ===== Discussion of Examples =====
-[[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-Table {{ref>opCyberRiskReqComment}} comments on those "desirements" identified by the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start&do=edit | White Paper]] and the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start | OMG's White Paper Analysis]] relating to [[cbdc:public:8_append:20_glossary:cbdc]] Operational or Cyber Risks. See: Table [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start#stakeholderReq | 5]] in Section [[cbdc:public:04_doc:15_common:05_stakeholder:start]].
+Table {{ref>opCyberRiskReqComment}} comments on those "desirements" identified by the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] and the [[cbdc:public:cbdc_omg:15_summary:start | OMG's CBDC WG White Paper Analysis]] relating to [[cbdc:public:cbdc_omg:8_append:20_glossary:cbdc]] Operational or Cyber Risks. See: Table [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start#stakeholderReq | 5]] in Section [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start]].
 <table opCyberRiskReqComment>
@@ Line 136: / Line 150: @@
 ^ Desirement No.  ^ Desirement Text  ^ Comment  ^
 ^ B0020 ^ Maintain public confidence by not requiring mechanisms, such as deposit insurance | <WRAP>
-This is highly dependent on the [[cbdc:public:04_doc:15_common:08_currency_models:start| Currency Model]] used for the CBDC. If it is [[cbdc:public:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash Model]] then the need for deposit money is nil, since there are no deposits (i.s., just like there is no insurance on U.S. Dollars).
+This is highly dependent on the [[cbdc:public:cbdc_omg:04_doc:15_common:08_currency_models:start| Currency Model]] used for the CBDC. If it is [[cbdc:public:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash Model]] then the need for deposit money is nil, since there are no deposits (i.s., just like there is no insurance on U.S. Dollars).
-However, if it is based on a [[cbdc:public:04_doc:15_common:08_currency_models:15_accounts:start| Digital Account Model]], then by definition there are accounts, and by experience, deposit insurance is required to stabilize (See: **''R0012''**) the assets stored in those accounts. Deposit insurance provides three important benefits to the economy:((
+However, if it is based on a [[cbdc:public:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start| Digital Account Model]], then by definition there are accounts, and by experience, deposit insurance is required to stabilize (See: **''R0012''**) the assets stored in those accounts. Deposit insurance provides three important benefits to the economy:((
 State of Connecticut, Department of Banking,
 __ABC's of Banking__,
@@ Line 159: / Line 173: @@
 Therefore, the key is to manage [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | risk]], which is the probability or threat of damage, injury, liability, loss, or any other negative occurrence caused by external or internal vulnerabilities, and that may be avoided through preemptive action.
-The goal of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] is to manage risk, including the risk of not delivering what the customer wants and needs, the risk of late delivery, the risk of excess cost, and the risk of negative unintended consequences. One measure of the utility of Systems Engineering activities is the degree to which such risk is reduced. Conversely, a measure of acceptability of the absence of a System Engineering activity is the level of excess risk incurred as a result.
+The goal of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] is to manage the risk, including the risk of not delivering what the customer wants and needs, the risk of late delivery, the risk of excess cost, and the risk of negative unintended consequences. One measure of the utility of Systems Engineering activities is the degree to which such risk is reduced. Conversely, a measure of acceptability of the absence of a System Engineering activity is the level of excess risk incurred as a result.
 </WRAP>|
 ^ B0048 ^ Provide a secure way for people to save |<WRAP>
@@ Line 174: / Line 188: @@
   : 2. cybersecurity risks
 </WRAP>|<WRAP>
-See the [[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start#overview| Overview of "What operational or cyber risks might be unavoidable?"]]
+See the [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start#overview| Overview of "What operational or cyber risks might be unavoidable?"]]
 </WRAP>|
 ^ B0054 ^ Attract risk-averse users to CBDC |<WRAP>
@@ Line 180: / Line 194: @@
 </WRAP>|
 ^ P0012 ^ The firms that operate interbank payment services are subject to federal supervision |<WRAP>
-See the detailed discussion in section [[cbdc:public:04_doc:15_common:48_natsec:start]].
+See the detailed discussion in section [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start]].
 </WRAP>|
 ^ P0017 ^ The PWG report recommends CBDC complement existing authorities regarding: <WRAP>
@@ Line 188: / Line 202: @@
 </WRAP>|<WRAP>
 See:
-  : 1. [[cbdc:public:04_doc:15_common:05_stakeholder:start]]
+  : 1. [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start]]
-  : 2. [[cbdc:public:04_doc:15_common:45_privacy:start]]
+  : 2. [[cbdc:public:cbdc_omg:04_doc:15_common:45_privacy:start]]
-  : 3. [[cbdc:public:04_doc:15_common:48_natsec:start]]
+  : 3. [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start]]
 </WRAP>|
 ^ P0020 ^ The private sector would offer accounts or digital wallets to facilitate the management of CBDC holdings and payments |<WRAP>
@@ Line 205: / Line 219: @@
   : // Cryptocurrency exchanges come and go, and it’s almost inevitable that an exchange will get hacked at one point or another. While cryptocurrencies themselves are very secure, exchanges can be affected by a variety of vulnerabilities, making them a prime target for malicious actors.//
-  : //State of the industry – February 2020: As it stands, 2019 saw a record number of twelve crypto exchanges being hacked. That being said, across the board the amounts of crypto stolen were worth less. In total, **\$292,665,886 worth of cryptocurrency and 510,000 user logins were stolen from crypto exchanges in 2019**.//
+  : //State of the industry – February 2020: As it stands, 2019 saw a record number of twelve crypto exchanges being hacked. That being said, across the board the amounts of crypto stolen were worthless. In total, **\$292,665,886 worth of cryptocurrency and 510,000 user logins were stolen from crypto exchanges in 2019**.//
   : //One would hope that as time goes on cryptocurrency exchanges would become more secure. The unfortunate reality is that more exchanges are hacked every year. As cryptocurrency and exchanges remain largely unregulated, it is unclear who has jurisdiction over cryptocurrency markets.//
@@ Line 220: / Line 234: @@
 </WRAP>|
 ^ P0021 ^ The intermediaries would operate in an open market for CBDC services |<WRAP>
-The lion's share of U.S. CBDC intermediaries will be building, delivering, and offering the services of software applications. This is not unlike the current situation in the smartphone world. However, the intermediary's applications will have to run not just on the smartphones, but also on personal computers, servers, and mainframes. The Federal Reserve and a U.S. CBDC must be able to achieve and retain the confidence of consumers that these applications are sufficiently robust and provide reliable security to hold their vital assets.
+The lion's share of U.S. CBDC intermediaries will be building, delivering, and offering the services of software applications. This is not unlike the current situation in the smartphone world. However, the intermediary's applications will have to run not just on smartphones, but also on personal computers, servers, and mainframes. The Federal Reserve and a U.S. CBDC must be able to achieve and retain the confidence of consumers that these applications are sufficiently robust and provide reliable security to hold their vital assets.
-Therefore, there is a need for a U.S. CBDC "application store" to act as a web portal through which end users can access, download and install U.S. CBDC-approved software applications that rigorous Assurance Case Models with which the quality and security of these applications is validated.
+Therefore, there is a need for a U.S. CBDC "application store" to act as a web portal through which end users can access, download and install U.S. CBDC-approved software applications that rigorous Assurance Case Models with which the quality and security of these applications are validated.
 See:
@@ Line 230: / Line 244: @@
 </WRAP>|
 ^ P0025 ^ CBDC intermediary would need to verify the identity of a person accessing CBDC |<WRAP>
-  : 1. If the [[cbdc:public:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash Model]] is used, then just like physical cash, there should be no IDs required.
+  : 1. If the [[cbdc:public:cbdc_omg:04_doc:15_common:08_currency_models:10_cash:start| Digital Cash Model]] is used, then just like physical cash, there should be no IDs required.
-  : 2. If the [[cbdc:public:04_doc:15_common:08_currency_models:15_accounts:start| Digital Account Model]] is used, it might depend on the rules placed on the intermediaries, Here are the rules for cashing checks in the U.S.:
+  : 2. If the [[cbdc:public:cbdc_omg:04_doc:15_common:08_currency_models:15_accounts:start| Digital Account Model]] is used, it might depend on the rules placed on the intermediaries, Here are the rules for cashing checks in the U.S.:
    : a. When cashing a check, people use an ID to complete the transaction. Banks are required to have an identity verification policy by the Federal Deposit Insurance Corporation, which is why an ID is necessary((
 Frank Gogol,
@@ Line 268: / Line 282: @@
   : 6. the cost and timing of implementation
 </WRAP>|<WRAP>
-See: [[cbdc:public:04_doc:15_common:50_international:start]]
+See: [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start]]
 </WRAP>|
 ^ R0011 ^ Increased **Risk** to consumer's vulnerability to: <WRAP>
@@ Line 275: / Line 289: @@
   : 3. fraud
 </WRAP>|<WRAP>
-If the U.S. CBDC avoids most of the safeguards built into the current U.S. financial system, then there is an increased risk of **loss**, **theft**, and **fraud**. Most of the laws and regulations outlined in section [[cbdc:public:04_doc:15_common:48_natsec:start]] have evolved over time in response to consumer demand for protection. Although it seems appealing, more efficient, and even "modern", consumers should demand the same level of protection from a U.S.-based CBDC.
+If the U.S. CBDC avoids most of the safeguards built into the current U.S. financial system, then there is an increased risk of **loss**, **theft**, and **fraud**. Most of the laws and regulations outlined in section [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start]] have evolved over time in response to consumer demand for protection. Although it seems appealing, more efficient, and even "modern", consumers should demand the same level of protection from a U.S.-based CBDC.
 According to Ryan Browne of CNBC((
@@ Line 293: / Line 307: @@
 See:
-  : 1. [[cbdc:public:04_doc:20_comments:brp:q13:sb_02:start#state_of_data|State of Data]]
+  : 1. [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start#state_of_data|State of Data]]
   : 2. [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.c_hwarch:network | OMG DIDO-RA Netword Devices]]
   : 3. [[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]]
@@ Line 309: / Line 323: @@
 </WRAP>|
 ^ D0016 ^ **Design** should include offline capabilities to help with the operational resilience of the payment system  |<WRAP>
-See: [[cbdc:public:04_doc:20_comments:dsn:q18:start]]
+See: [[cbdc:public:cbdc_omg:04_doc:20_comments:dsn:q18:start]]
 </WRAP>|
 ^ D0017 ^ **Design** should include digital payments in areas suffering from large disruption, such as natural disasters | <WRAP>
-See: [[cbdc:public:04_doc:20_comments:dsn:q18:start]]
+See: [[cbdc:public:cbdc_omg:04_doc:20_comments:dsn:q18:start]]
 </WRAP>|
-| **''B''** = [[cbdc:public:04_doc:12_summary:start#benefits| Benefit Considerations ]] |||
+| **''B''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#benefits| Benefit Considerations ]] |||
-| **''P''** = [[cbdc:public:04_doc:12_summary:start#policy_considerations| Policy Considerations]] |||
+| **''P''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#policy_considerations| Policy Considerations]] |||
-| **''R''** = [[cbdc:public:04_doc:12_summary:start#risks| Risk Considerations ]] |||
+| **''R''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#risks| Risk Considerations ]] |||
-| **''D''** = [[cbdc:public:04_doc:12_summary:start#design| Design Considerations]] |||
+| **''D''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#design| Design Considerations]] |||
 </table>
-<color blue><todo @nick>Need to explain difference between "specification" and "standard" better. Should be included in Glossary.  Suggestion that perhaps the term "specification standard" would be better given that the government tends to treat 'standards' and 'specifications' as equivalent. (from Steve McL)</todo></color>
-<color blue><todo @nick>Suggestion to add glossary items from Table 1 should be ignored given that these terms are defined in the DIDO RA glossary and a link is provided to it.  In fact, rule should be that if a term is already linked to a glossary item in the DIDO RA, there is no need to clutter up the Glossary for this report with them. (From Steve McL)</todo></color>
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

User Tools

Site Tools

Differences

Page Tools