Add issues requesting further comment from external groups.
authorManu Sporny <msporny@digitalbazaar.com>
Mon, 30 Mar 2015 23:15:27 -0400
changeset 661 cc9e18a2c62b
parent 660 ae7d4e5d3316
child 662 7d9adaa17c6f
Add issues requesting further comment from external groups.
latest/use-cases/index.html
--- a/latest/use-cases/index.html	Mon Mar 30 22:00:47 2015 -0400
+++ b/latest/use-cases/index.html	Mon Mar 30 23:15:27 2015 -0400
@@ -280,6 +280,15 @@
         </li>
       </ul>
 
+      <p class="issue">
+The group seeks input from security, privacy, and accessibility experts.
+Examples of desired groups to perform these reviews are, but are not
+limited to: W3C Privacy Interest Group,
+W3C Security Interest Group, W3C Web Accessibility Initiative and
+Protocols and Formats Working Group, US Federal Reserve Security Panels,
+X9 Security subgroups, and ISO security subgroups.
+      </p>
+
       <p>
 The Interest Group (currently) regards some of the use cases as "essential" to
 addressing their
@@ -382,6 +391,16 @@
 either of which could be a person, business, government, or software
 agent), which we organize into four phases:</p>
 
+    <p class="issue">
+The group would like feedback related to the general structure of the payment
+phases from individuals that worked on ISO20022, ISO12812, the
+European Payment Commission, and
+various X9 documents to ensure that the phases reflect business processes
+outlined in financial standardization initiatives. Feedback from the general
+public is also requested to see if non-payment professionals can navigate and
+understand the document without prior payment industry knowledge.
+    </p>
+
     <ol>
       <li>
 Negotiation of Payment Terms
@@ -566,6 +585,13 @@
 the payment phases</a>.
     </p>
 
+    <p class="issue">
+General feedback is requested as to whether or not this section is helpful in
+grounding the payment phases and steps in a real world use case is helpful this
+early in the document. An alternative would be removing this section
+entirely if the precending section is enough.
+    </p>
+
     <section>
       <h3>Negotiation of <a>purchase</a> Terms</h3>
 
@@ -715,6 +741,14 @@
 process.
     </p>
 
+    <p class="issue">
+General feedback is requested related to the general structure of the
+use case snippets below. Are they focused enough to convey each topic listed?
+Is there information that should be added to each use case in general? Would
+more elaborate use cases be helpful. Would an attempt to minimize each existing
+use further be helpful in scanning the document more quickly?
+    </p>
+
     <section>
       <h3>Negotiation of Payment Terms</h3>
       <p>
@@ -1640,7 +1674,7 @@
 Before subjecting a person or organization to any financial <a>transaction</a>
 commitment (such as a web payment), they should be presented with the option
 of reversing, checking, or confirming their choice or submission. It should
-also be noted that this does not preclude certain <a>transaction</a> operations 
+also be noted that this does not preclude certain <a>transaction</a> operations
 from being automated once they have been authorized by an <a>entity</a>.
 </a>For more details, see the section on
 <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-reversible">Error Prevention (Legal, Financial, Data)</a>
@@ -2087,6 +2121,14 @@
 illustrate the phase steps.
     </p>
 
+    <p class="issue">
+Input is requested from experts at each organization providing services
+mentioned below as well as engineers and designers of technologies used below.
+Specifically, if the payment flows outlined below contain errors or omissions
+the group would like to be to ensure that the oversight is corrected as soon
+as possible.
+    </p>
+
     <section>
       <h3>Credit Card Purchase</h3>
       <p>