[Fiware-security] FI-WARE Security - Outcomes of today's audio with CA regarding Security AT contrib to D2.3 (some work needed)

[BISSON Pascal]

Excellent many thanks for this final check/polish regarding Data Handling GE that for me is now perfectly fine and so ready to be published.

As for Optional Security enablers I know that Lucie is working hard completing the description.

Last remark, regarding DBAnomyzer I see "Basic concepts" section missing. May be worth to add one for the sake of conformance to the Table of Content. 

Regards,
Pascal

-----Message d'origine-----
De : DI CERBO, Francesco [mailto:francesco.di.cerbo at sap.com] 
Envoyé : lundi 5 mars 2012 17:20
À : BISSON Pascal; GASPARD Lucie; Alexandre Boeglin; LELEU Philippe
Cc : GIDOIN Daniel; Pedro Soria Rodriguez; fiware-security at lists.fi-ware.eu; TRABELSI, Slim; Seidl, Robert (NSN - DE/Munich); gabor.marton at nsn.com; norbert.goetze at nsn.com; osb at zurich.ibm.com; anj at zurich.ibm.com; antonio.garcia at atosorigin.com; Antonio Garcia Vazquez; Wolfgang.Steigerwald at telekom.de
Objet : RE: FI-WARE Security - Outcomes of today's audio with CA regarding Security AT contrib to D2.3 (some work needed)

Hello Pascal,
Thanks for your comments. As you remarked, many points were already addressed, nevertheless I went through all of them again, and you can find in the text of the previous email a log of all old and new modifications.

Now at least for the Data Handling GE we should be absolutely aligned with whatever was requested.

With respect to the Optional Security Services, I think that Morphus part is aligned with what was requested, but I hope that Philippe/Lucie are still working on this (for instance, on the Glossary, on the FMC block diagram...)

Kind regards,

Francesco

> -----Original Message-----
> From: BISSON Pascal [mailto:pascal.bisson at thalesgroup.com]
> Sent: lundi 5 mars 2012 16:25

> some comments or suggestions that Juanjo would have like to be addressed
> (e.g. "I would also suggest to elaborate on the following concepts: PPL and
> PPI, PPL Privacy Tuner tool", "It would be nice to describe what PPL stands for,
> the first time this acronym is used" ...)

> 
> As for Optional Security enablers descriptions I do think his claim was that
> they were not compliant with the Table of content suggested and used by
> each of our GEs (also some diagrams were not FMC conformant). This is also
> something which could be improved with support of INRIA and Thales (TAI)
> who owns those enablers.
> 
> Hope I have answered and clarified.
> 
> Thanks in advance for your final check and polish.
> 
> Hearing from you and best regards,
> 
> Pascal
> 
> PS: For your convenience here are the comments got from Juanjo (you mostly
> addressed).
> 
> 
> 1.5. Data Handling GE
> 
>   I would review writing of the example scenario.  Some comments (part of
> them editorial, but I have decided to compile all them together here):

Scenario was rewritten-modified to be compliant with all comments.

> 
>   There is no section on "Basic Concepts".   Probably it would make sense to
> translate some of the content in the Appendix here (if you decide to move
> everything, just the reference would be kept at the end).   I would also suggest
> to elaborate on the following concepts:
> •	PPL and PPI

Added a subsection in basic concepts

> •	PPL Privacy Tuner tool

Removed any reference to the Privacy Tuner, as it will be not part of the 1st release, and should be replaced by the integration with other GEs

>   Figure on Architecture should be adapted to follow FMC notation.   On the
> other hand, it would be nice to illustrate there:
> •	What is the role of the Privacy Tuner ?  Please try to illustrate it
> •	Is the left big grey box a description of the architecture linked to the
> "PPL Privacy Engine" ?  If so, name it accordingly.   Otherwise ... what
> components would be linked to the PPL Privacy Engine ?

Picture has been updated, indicating explicitly the Data Handling GE, that is composed by 3 high-level components

>   Main interactions after the Architecture figure:
> •	You describe interactions in terms of operations described in some
> sort of description of a RESTful binding.   This doesn't follow the reference
> example provided as guidelines.   As a result, it is too austere and doesn't
> elaborate on who invokes an operation, for example.  Sequence diagrams
> would be useful.

A sequence diagram is provided, together with its linking with the use case scenario, and the following API.

> •	The suggested structure for the "Main Interactions" section is fine
> though:

Outline adjusted as requested

> 
> 1.6 Optional Security Enablers:
> 
>   I understand the Architecture Description of these enablers, and particularly
> adaption to published guidelines, is under way.  Therefore, I will wait until
> they are more elaborated.
> 
> 
> 2.2 Data Handling GE
> •	I may be wrong but it seems to me like there is something missing or
> wrong (from an editorial point of view) in the following sentence: "It supports
> integrated data handling, in particular through two-sided detailed data
> handling, that takes into account specific preferences/policies expressed using
> the PPL language, based on XACML".

Sentence modified.

> •	It would be nice to describe what PPL stands for, the first time this
> acronym is used.   Same for PII.

Addressed