RE: SPA Document Posted On GitHub

Hei Joe.

Thank you for the editorial comments. I will go through those, as I just did a merge of comments from Art Barstow, to make sure they are all taken into account.

<snip/>
> * Am I right in thinking that the second if/then in the flowchart in Section 2
> which says, "Will std or spec generate data?" is a bit broad?
> Is any generation of data really a trigger for privacy review? Do we want to
> have such a hair trigger? I can imagine maybe the rationale for a hair trigger is,
> "Well, if it's innocuous data generation, you won't have much of the SPA to
> do." I guess I wonder if that piece can't be fine-tuned a bit more. Maybe "Will
> std or spec generate personal data?"

The concern with specifying "personal data" rather than "data" is that analysis of the context is needed to determine if data generated is "personal data" or not. So, gate the need of a SPA on whether data is generated and it may end up that analysis shows no personal data so SPA is abridged. 

<snip/>
> 
> * Do we really need to acronymize specification under review (SUR)?
> Can't we just s/SUR/spec/g ?
My editorial preference was to refer to the specification under review. After seeing that this same text appeared multiple times, I cloned the use of "Implementation Under Test" used in conformance testing area into SUR. As a software engineer, I am not against "acronimization" :-)

<snip/>
> 
> * step 5: Are there good pointers to threat analysis/modeling materials that
> someone conducting a SPA can use to give them an idea or recipe on how to
> do that?
Yes. Refer to the following:

Open Web Application Security Project: https://www.owasp.org/index.php/Application_Threat_Modeling#Threat_Analysis

Microsoft Threat Mitigation Analysis: http://msdn.microsoft.com/en-us/library/aa561499.aspx
10-Minute DFD: http://www.prestwood.com/ASPSuite/KB/document_view.asp?qid=100887


These could be added as references.

Frank/

Received on Friday, 21 June 2013 16:06:27 UTC