SEVENTH FRAMEWORK PROGRAMME Challenge 1 Information …

SEVENTH FRAMEWORK PROGRAMMEChallenge 1Information and Communication Technologies

Document type Report

Title D12- Requirements Assessment Report

Work Package WP1

Deliverable Number D12

Editor(s) S Gurses KU Leuven N Zannone TUE

Dissemination level Public

Preparation date 30 June 2010

Version 20

Legal NoticeAll information included in this document is subject to change without notice The Membersof the TAS3 Consortium make no warranty of any kind with regard to this document includ-ing but not limited to the implied warranties of merchantability and fitness for a particularpurpose The Members of the TAS3 Consortium shall not be held liable for errors containedherein or direct indirect special incidental or consequential damages in connection withthe furnishing performance or use of this material

D12ndash REQUIREMENTS ASSESSMENT REPORT Page 3 of 196

The TAS3 Consortium

Nr Participant name Country Participant short name Participant role1 KU Leuven BE KUL Coordinator2 Synergetics BE SYN Project Manager3 University of Kent UK KENT Partner4 University of Karlsruhe BE KARL Partner5 Technische Universiteit

EindhovenNL TUE Partner

6 CNRISTI IT CNR Partner7 University of Koblenz-

LandauDE UNIKOLD Partner

8 Vrije Universiteit Brussel BE VUB Partner9 University of Zaragoza ES UNIZAR Partner10 University of Nottingham UK NOT Partner11 SAP Research DE SAP Partner12 Eifel FR EIF Partner13 Intalio FR INT Partner14 Risaris IR RIS Partner15 Kenteq BE KETQ Partner16 Oracle UK ORACLE Partner17 Custodix BE CUS Partner18 Medisoft NL MEDI Partner

Contributors

Version 20

Name Organisation1 Antonia Bertolino CNRISTI2 David Chadwick KENT3 Danny DeCock KU Leuven4 Brendan van Alsenoy KU Leuven5 Jeroen Hoppenbrouwers KU Leuven6 Lex Polman KETQ7 Carlos Flavian UNIZAR8 Sandra Winfield NOT9 Sampo Kellomaki SYM10 Marc Van Coillie EIF11 Marc Santos KOBLENZ12 Jerry den Hartog TUE13 Joseph Alhadeff ORACLE14 Brecht Claerhout CUS15 Luk Vervenne Synergetics16 Jens Muller KARL17 Jutta Mulle KARL18 Gilles Montagnon SAP

Version 20

Table of Contents

1 EXECUTIVE SUMMARY 9

2 INTRODUCTION 11

21 SCOPE AND OBJECTIVES 11

22 GAP ANALYSIS 12

23 REQUIREMENTS ELABORATION 12

24 INTERACTION ANALYSIS 14

241 Inner WP Requirements Interaction (I1) 14

242 Inter-WP Requirements Interaction (I2) 15

243 Requirements interaction with Architecture (I3 and I4) 15

244 Reiteration of Inter-WP Requirements Interaction (I5) 15

245 Interaction of Legal and Technical Requirements (I6 and I7) 17

246 Validation of Requirements with the Architecture (I8 and I9) 18

25 STRUCTURE OF THE DOCUMENT 19

I DELIVERABLE 12 REQUIREMENTS ASSESSMENT REPORT 20

3 OBJECTIVES OF TAS3 REVISITED 21

31 OBJECTIVES OF WP2 22

4 REQUIREMENTS INTERACTION IN TAS3 WORK PACKAGES 30

41 REQUIREMENTS INTERACTION IN WP3 30

Version 20

49 REQUIREMENTS INTERACTION IN WP 12 39

5 INTER-WORK PACKAGE TECHNICAL REQUIREMENTS INTERACTIONS 41

51 SIMILARITY ANALYSIS 41

52 INCONSISTENCY ANALYSIS 43

6 LEGAL AND TECHNICAL REQUIREMENTS INTERACTION ANALYSIS 44

61 INTERACTION ANALYSIS OF NEW LEGAL REQUIREMENTS 59

62 MAPPING OF LEGAL REQUIREMENTS TO ARCHITECTURE 61

7 MAPPING GLOBAL REQUIREMENTS TO THE TAS3 ARCHITECTURE 69

8 MAPPING WP REQUIREMENTS TO THE TAS3 ARCHITECTURE 77

81 GAPS 99

9 REQUIREMENTS FULFILLED BY EXISTING SOLUTIONS 101

91 EXISTING SOLUTIONS CONSIDERED AND SELECTED BY WP 3 7 AND 10 (CNR) 101

92 EXISTING SOLUTIONS CONSIDERED AND SELECTED BY WP 4 AND 5 102

93 EXISTING SOLUTIONS CONSIDERED AND SELECTED BY WP 8 104

95 EXISTING SOLUTIONS CONSIDERED AND SELECTED BY WP 10 (UNIZAR) 105

97 EXISTING SOLUTIONS CONSIDERED AND SELECTED BY WP 2 (VUB) 106

10 REQUIREMENTS THAT CALL FOR NEW SOLUTIONS 107

101 ACTIVITIES OF WP2 107

Version 20

11 CONCLUSION 116

BIBLIOGRAPHY 117

II DELIVERABLE 12 SUPPORTING DOCUMENTS 119

A REQUIREMENTS ASSESSMENT TEMPLATES 120

A1 TEMPLATE 1 FOR GAP ANALYSIS AND REQUIREMENTS ELABORATION 120

A2 TEMPLATE 2 FOR INTER-WP INTERACTIONS 121

A3 TEMPLATE 3 FOR REQUIREMENTS UPDATES 121

B UPDATES TO REQUIREMENTS OF TAS3 124

B1 NEW REQUIREMENTS OF TAS3 124

B2 EDITED REQUIREMENTS OF TAS3 127

B3 DELETED REQUIREMENTS OF TAS3 130

C REQUIREMENTS OF TAS3 132

C1 GENERAL REQUIREMENTS OF TAS3 132

C2 REQUIREMENTS OF WP2 133

Version 20

D EXISTING SOLUTIONS 158

E INTER-WP REQUIREMENTS INTERACTIONS (FIRST ITERATION) 175

E1 INTERACTIONS OF WP2 175

E4 INTERACTIONS OF WP 5 178

F INTER-WP REQUIREMENTS INTERACTION (SECOND ITERATION) 188

F1 INTERACTIONS OF WP3 188

Keyword List

Requirements assessment Gap analysis Requirements elaboration

Version 20

1 Executive SummaryThis document presents the final (third) iteration of Deliverable 12 The objective of D12

is to gather requirements regarding unsolved problems in the field of security and trust inservice-oriented open and distributed environments that apply to the TAS3 project Specifi-cally the deliverable translates the design requirements defined in Deliverable 14 [22] intothe research and development activities that will be carried out in the different TAS3 WPs

In order to fulfill the objectives of this deliverable we have completed a number of se-quentially ordered activities The results of these activities are documented in the differentsections while some of the material we used and collected is included in the Appendices

During the first iteration we have reviewed the objectives of each work package andthe solved and unsolved problems they are addressing with respect to the objectives oftheir work package Next we asked partners to elaborate or refine requirements based onthese objectives and scenarios provided by the demonstrators in D14 Then we comparedthe requirements elaborated by the TAS3 partners with the existing solutions for trust andsecurity in service-oriented open and distributed environments We then identified researchand development challenges to be addressed by the partners in their future activities in orderto fulfill their requirements Last we mapped the requirements to the TAS3 architecture

In addition in order to prioritize activities and discover interdependencies within andamong work package activities we analyzed requirements interactions in each WP andbetween WPs The WP-internal interactions are represented in the form of graphs to sup-port the analysis The inter-WP interdependencies are captured in tables and later analyzedusing a tool to detect inconsistency candidates In the second and third iteration of D12 werepeated the requirements elaboration steps to capture the evolution of the requirementsFurther we re-iterated the analysis of inter-WP requirements interactions in order to findinconsistencies and incompleteness in the D12 requirements

Next once the consistency and completeness analysis was completed we completedanother interaction analysis activity between the refined legal requirements elaborated byWP6 and the technical requirements of the WPs Finally we validated the consistency ofthe requirements in D12 with the architecture of TAS3

Hence the contribution of the deliverable is threefold First it provides a gap analysiswhich is used to map out future activities Second the deliverable elaborates on the techni-cal legal and application domain requirements of TAS3 Finally the inter-WP requirementsinteraction analysis provides the partners with an understanding of the relationships be-tween WP requirements and provides the grounds upon which to assign responsibilitiesand detect cooperation needs between partners

Readers Guide We have added a number of chapters or expanded existing ones to in-clude all the activities and results in all iterations of D12 The introduction has been ex-panded to give an overview of all the activities that were part of D12 Most activities inthe second and third iteration of D12 have concentrated on consolidating the different view-points of the technical work packages integrating the legal and technical requirements andvalidating the requirements with the architecture In order to achieve these objectives weconducted a number of interaction analysis activities

Specifically in Section 5 we provide an overview of how we analyzed the interaction of

Version 20

technical requirements of different technical and application domain oriented WPs and theresults achieved We moved the documentation of the interactions to Appendix E and F Theanalysis of the interaction of legal and technical requirements and the resulting gap analysisis documented in Section 6 The mapping of global requirements to the architecture and therelated gap analysis is provided in Section 7 Finally the mapping of all technical require-ments to the architecture and the gap analysis is provided in Section 8 All the templates wesent out to the partners for requirements requirements interactions and existing solutions isincluded in Appendix A We added Section B to document all the additions and changes tothe requirements due to the re-iteration of requirements elaboration and the various require-ments interaction analysis activities Last we added some new insights into the conclusionin Section 11

The following chapters remained identical with the first iteration of Deliverable 12 Section3 provides a review of the objectives of each work package and the objectives are relatedto solved and unsolved problems in the field of security and trust in service-oriented openand distributed environments Section 4 provides an analysis of the technical legal andapplication domain requirements that address the solved and unsolved problems related toTAS3 The technical legal and application domain requirements elaborated for D12 are doc-umented in Appendix C This detailed listing of the requirements includes the justificationsfor each requirement and the interactions of each requirement within each WP

Section 9 provides an analysis of the requirements fulfilled by existing solutions Thejustifications for selected solutions are summed up in Section 9 and are included in detail inAppendix D Section 10 lists the activities that each work package has to complete in orderto fulfill the requirements that cannot be fulfilled using existing solutions Section 7 maps theWP requirements to the Architecture

Version 20

2 Introduction21 Scope and Objectives

The objective of Deliverable 12 is to gather requirements about unsolved problems in thefield of security and trust in service-oriented open and distributed environments that apply tothe TAS3 project Specifically the deliverable translates the design requirements defined inDeliverable 14 [22] into the research and development activities that will be carried out in thedifferent TAS3 WPs Here we revisit and refine the requirements presented in Deliverable14 [22] and take Deliverable 11 [25] on State of the Art as well as the objectives of TAS3

as a reference in order to provide a gap analysis This deliverable is hence different in itsmain focus than D14 which focuses on requirements elicitation

There are two main objectives fulfilled by this deliverable

bull the identification of the activities that will be performed by each WP in the course ofthe project based on a gap analysis

bull the identification of the relationships among the activities of WPs with respect to therequirements that need to be fulfilled in order to realize the TAS3 architecture

The gap analysis presented in this document serves as a basis for the identification ofthe activities and research challenges that will be addressed by the WPs in the course ofthe project In order to complete the gap analysis it is first necessary to elaborate on therequirements that each of the WPs need to fulfill for the realization of the TAS3 architectureand how these interact with each other A detailed description of the methods and processthat was used by the TAS3 partners for the gap analysis are given in Sections 22 through24

Communication with Partners In the first iteration of D12 we communicated with thepartners through emails and during face-to-face meetings In the later iterations of D12we used the Trac Wiki tool which was introduced to the project by WP12 The Trac Wikitool provides a collaborative environment in which partners can also view the contributionsof other partners Especially inter-WP requirements interaction analysis required intensivecommunication among partners The Trac Wiki offered us the collaborative environment tomitigate some of the problems that arise when a distributed requirements engineering teamhas to interact intensively Further we are able to integrate and edit Graphviz1 DOT2 filesin Trac Wiki pages This allowed us to address problems with the presentation of Inter-WPinteractions as we discussed in Section

In addition in the re-iteration of the deliverable we organized four workshops with thepartners In the first workshop we provided an overview of the steps to come In thesecond workshop we completed the analysis of inter-WP requirements interactions In

1Graphviz is open source graph visualization software The Graphviz layout programs take descriptionsof graphs in a simple text language and make diagrams in several useful formats such as images and SVGfor web pages Postscript for inclusion in PDF or other documents or display in an interactive graph browserhttpwwwgraphvizorg

2DOT draws ldquohierarchicalrdquo or layered drawings of directed graphs The layout algorithm aims edges in thesame direction (top to bottom or left to right) and then attempts to avoid edge crossings and reduce edge length

Version 20

the third workshop we executed the analysis of interactions between legal and technicalrequirements The final workshop was used to validate the requirements by mapping themto the architecture together with the architecture team

22 Gap Analysis

A gap analysis is a process of identifying delta between the current situation and the futuredesired situation [8] Therefore a gap analysis requires both establishing the state of the artand the missing elements with respect to the desired future state The two other deliverablesin Work Package 1 provide the necessary building blocks of a gap analysis the state-of-the-art of trust and security in service oriented architectures in D11 [25] and definition of thedesign requirements that the future TAS3 architecture should fulfill in D14 [22]

To perform a gap analysis based on these two documents we took the following steps

Step 1 Define objectives and problems The partners revisited the objectives of their workpackages with respect to the objectives of TAS3 They were also asked to identifysolved and unsolved problems in the field of trust and security in service oriented en-vironments in the scope of their work package

Step 2 Elaborate requirements The partners elaborated on the technical legal and ap-plication domain requirements that they had to fulfill to achieve the objectives of TAS3

and the objectives of their work package

Step 3 Identify existing solutions The partners listed existing solutions that addressedthe solved problems they had identified in Step 1 They further stated which of theirrequirements elaborated in this deliverable were fully or partially fulfilled given the ex-isting solutions

Step 4 Plan future activities The partners identified the activities that are necessary tofulfill the requirements that are not addressed by existing solutions and stated howthey plan to validate the fulfillment of these requirements

Part of the gap analysis activity included the elaboration and analysis of the technicallegal and application domain requirements of TAS3 We shortly describe the methods weused for this step in the gap analysis in the next section

23 Requirements Elaboration

We preferred a template based methodology for requirements elaboration and analysis sinceit is an accepted standard approach to requirements engineering and produces comparableresults among many work packages We prepared and distributed a template to the part-ners to elicit their technical legal and application domain requirements that they have to fulfillwith their work package activities in order to achieve the objectives of TAS3 The partnerswere expected to make use of the two prior deliverables D11 for state-of-the-art for the gapanalysis and D14 for the requirements elaboration During this phase we supported thepartners mostly through written electronic communication but also through phone confer-ences and occasional face-to-face meetings In the process we iteratively reviewed all the

Version 20

inputs from the partners in order to reach a comparable level of requirements and activitygranularity among many partners and 10 WPs

The template for requirements elaboration (See Template 1 in Appendix A) was based onthe two methodologies for template based requirements elicitation The first one is a popularindustrial requirements elicitation template called Volere [26] and a second template whichis described in [27] We preferred to use the latter for its simplicity and enhanced it usingVolere Purpose of the project the scope of the work etc were questions from Volere thatwe included to support the gap analysis

The template in [27] defines the following mandatory fields requirement id version au-thor source purpose description time interval importance urgency comments Of thesefields we used requirement id source justification (instead of purpose as it better con-ditioned the author to state why the requirement is necessary) requirements (instead ofrequirement description for brevity) The other fields were addressed through the versioningof the deliverable itself (version) the list of contributors (author) and our later interactionanalysis (importance urgency and comments) In a different version of their template forfunctional requirements the authors in [27] suggest integrating also a use case templatesimilar to that defined by [10] We avoided this in order to keep the separation between thisdeliverable and Deliverable 14 [22] which works with detailed scenarios Participants wereencouraged to make use of those scenarios but not to repeat them in this deliverable

For the first interaction analysis activity we asked partners to fill out a field in the tem-plate for interactions among their requirements within their work package We provided acontrolled vocabulary which consisted of the following elements

bull A depends on B requirement A requires requirement B B is a condition for A

bull A supports B requirement A is needed to fulfill requirement B A is a condition for B

bull A implements B requirement A is a specialization of requirement B

bull A abstracts B requirement A is a generalization of requirement B

bull A is in conflict with B requirement A and requirement B are logically inconsistent orthe implementation of both requirements is not feasible

There were two further iterations of Deliverable D12 In the second year of the project theTAS3 partners made considerable progress with respect to the implementation of the TAS3

architecture This also led to changes in requirements some requirements were eliminatedand changed additional requirements were captured We asked the partners to documentthese changes in a WP specific wiki page For each edited or deleted requirement partnerswere asked to provide a justification For additional requirements the partners had to fulfillthe requirements template provided in the initial iteration of D12 which also includes ajustification of the requirement (See Requirements Template 3 in Appendix A)

In particular the following five objectives were met through the re-iterations of the deliver-able

bull review and update the elaborated requirements in order to capture changes and ad-ditional requirements

Version 20

bull re-iterate the inter-WP requirements interactions in order to detect and solve inconsis-tencies and check for completeness

bull update used solutions and validation plans of each WP

bull integrate the legal requirements to the finalized requirements

bull map the requirements to the architecture in order to validate the finalized requirements

We explain in more detail the interaction analysis activities in the next section

24 Interaction Analysis

Technical Reqs ArchitectureLegal Reqs

I2 I5 (inter WP)

I1 (inner WP)

Figure 21 Overview of interaction analysis activities in D12 The numbers indicatethe order of the activities

Figure 21 provides an overview of the nine interaction analysis activities executed duringthe various iterations of D12 In Sections 241 through 246 we describe the interactionanalysis activities that we executed in D12

241 Inner WP Requirements Interaction (I1)

Once all the requirements were elaborated we analyzed the inner-WP requirement inter-actions For the inner-WP interaction analysis we visualized the interactions with diagrams

Version 20

in order to improve the readability and resulting analysis as suggested in [4] The dia-grams in Section 4 were inspired by [21] where responsibilities with respect to requirements-dependency social networks are mapped out to determine team members who are likely towork together and who would play an important role in requirements traceability

In particular we used requirements graphs based on [21] In requirements graphs eachnode indicates a requirement of the workpackage and labeled edges indicate the type ofinteraction between requirements Circles around the graph indicate the workpackage fromwhich the requirements originate We used requirements graphs to discuss and prioritizethe requirements of each WP The final visualization and evaluation were validated by thecorresponding partners

242 Inter-WP Requirements Interaction (I2)

To integrate the WP viewpoints into a monolithic consistent requirements document weasked WP partners to document the interactions of requirements across workpackagesfrom now on referred to as the inter-WP requirements interaction We used the same con-trolled vocabulary used for the inner workpackage interactions We added rdquoA is similar to Brdquoto the controlled vocabulary for inter-WP interaction analysis as recommended by [1] Wedid this in order to determine overlapping or redundant requirements across work packagesThe inter-WP interactions were then captured using a template (See Template 2 in AppendixA)

We tried to visualize the inter-WP requirements interactions but these visualizations ac-tually did not enhance readability Hence we included the templates as provided by thepartners according to their viewpoints then modeled the interactions as a graph and usedthis graph to look for inconsistency candidates We describe our approach to inter-WP inter-action analysis in more detail in Section 244

243 Requirements interaction with Architecture (I3 and I4)

In addition to the Inter-WP interaction analysis among the different partners we asked thearchitecture team to map the requirements of the different WPs to the architecture We askedthem to fill a simple template mapping each requirement to a component of the architectureincluding an explanation of how the component will fulfill that requirement The architectureteam also documented redundancies and requirements that are out of the scope of thearchitecture The results were communicated back to the WPs and the necessary updateswere conducted in the requirements list in the first iteration of D12

244 Reiteration of Inter-WP Requirements Interaction (I5)

As mentioned earlier graphical models for analysis often suffer scalability issues dependingon the granularity of the analysis needed In our case the direct visualization of inter-WPrequirements interactions fell apart after 20 requirements Hence simple visualization is notappropriate for representing inter-WP interactions between the 163 requirements in Deliver-able 12 To address the scalability issues we developed our own automated analysis toolthat detects inconsistency candidates and visualize only the relevant parts of the require-ments graphs We used the initial round of input with respect to inter-WP interactions to

Version 20

study the type of inconsistencies that occur among the requirements of the different WPsand to develop an inconsistency detection tools

The inconsistency detection tool is used to find inconsistency candidates Inconsistencycandidates include groups of requirements that are indicated by the WP partners to eitherbe conflicting or similar Further we developed a catalog of patterns which may point tofurther inconsistency candidates These patterns detect

bull homogeneous interaction cycles cycles with the same interaction type eg ldquoA de-pends on Brdquo ldquoB depends on Crdquo and ldquoC depends on Ardquo

bull heterogeneous interaction cycles cycles which are not homogeneous and may be un-reasonable eg if ldquoA depends on Brdquo and ldquoB abstracts Ardquo it means that a requirementdepends on its abstraction

bull non-cyclic interactions these patterns identify the combinations of unacceptable multi-ple edges eg ldquoA supports and depends on Brdquo as well as unreasonable combinationscomparable to heterogeneous interaction cycles eg ldquoA supports and abstracts Brdquo

After repeating the elaboration of requirements and capturing all the new edited anddeleted requirements of the WP we re-iterated the inter-WP requirements interaction analy-sis using the inconsistency detection tool

We first asked the partners to address requirements that were indicated as similar orconflicting At the end of this activity similar requirements were either merged or their dif-ferences were better articulated and conflicting interactions between requirements wereresolved

We then used our inconsistency detection tool to generate requirements graphs of incon-sistency candidates These become our inconsistency graphs We integrated the inconsis-tency graphs into the Trac Wiki system using GraphViz DOT The partners were then askedto comment on the inconsistencies to suggest changes to interactions between require-ments or to change the requirements The suggested changes are then validated by thepartners The results were then fed back into the inconsistency detection tool to check ifnew inconsistencies surfaced as a result of the changes

A preliminary analysis using the inconsistency detection tool following the resolution ofsimilarities and conflicts revealed 20 similarities 62 homogenous cycles and 3 heteroge-nous cycles These inconsistency candidates based on patterns were discussed and re-solved with the partners during a requirements interaction analysis workshop with all part-ners

This interaction analysis activity requires multiple synchronization steps among the part-ners with a high communication overhead The intermediary synchronization between stepshave to be well planned since changes provided by any WP may affect the interactions withother requirements In addition inconsistency analysis can be reiterated infinitely Know-ing when to stop the analysis requires balancing the level of requirements consistency withpartnersrsquo time and motivation Trac wiki provides an environment to analyze and resolveinconsistencies collaboratively However it can lead to confusion especially if unexpectededits are executed by partners In the following paragraphs we explain the rest of the inter-action analysis activities including details on how we deal with problems of scalability andcompleteness during interaction analysis activities

Version 20

245 Interaction of Legal and Technical Requirements (I6 and I7)

The interaction of legal requirements with technical requirements is an under-researchedmatter where the accumulation of past experience is minimal Previous work in this fieldfocuses on the articulation of data protection legislation as requirements [ ] but not onhow legal and technical requirements can be consolidated during requirements engineeringHowever due the nature of legal requirements the relationship between legal and technicalrequirements need to be expressed differently than technical requirements among eachother Further in the second iteration of WP6 the legal requirements were refined from17 requirements to over 60 legal requirements and this required a systematic approach tointeraction analysis between legal and technical requirements

We identified the following steps in order to complete an analysis of the interaction of legalrequirements with technical requirements

1 identify data protection requirements that can be fully or partially technically satisfied

2 identify data protection requirements that cannot be technically satisfied

3 identify legal requirements elaborated by other WP partners

Further in order to complete this partitioning we designed the following interaction tem-plate

SourceRequire-ment

InteractionType

Target Requirements

D12-6X

is fulfilled byis partially ful-filled bynot fulfilledconflicts withcomments

This requirement will be fulfilled by WPs

In this template the vocabulary is to be interpreted as follows

bull is fulfilled by 1-on-1 (exact match) OR technical requirement covers more than thelegal requirement

bull is partially fulfilled by technical requirement covers a part of legal requirement

bull conflicts with in case the implementation of the technical requirement would violatethe legal requirement

bull comment used to describe why it is not yet sufficiently supported (but should be) andstates whether for the fulfillment of the legal requirement additional work is neededand if so which work packages would be responsible to articulate the requirements ordevelop the necessary components

Version 20

After the technical requirements interaction analysis was completed WP6 reviewed the(revised) requirements list to evaluate the extent to which legal requirements were sufficientlyaddressed as well as to evaluate whether or not there were any legal requirements missingThe extent of fulfillment (complete partial not at all) of the legal requirements through thetechnical requirements was documented by WP6 in the legal-technical requirements interac-tion analysis template Where it was found that there was no adequate technical counterpartto satisfy the legal requirement WP6 documented which items were still missing (under thecomment section of the template with the title requires additional work)

Once all of these items requiring additional work were documented a workshop wasorganized to discuss and decide which WP shall be responsible for ensuring that a givenlegal requirement will be satisfied This proved to be a useful exercise not only for completingthe interaction analysis but also to raise awareness with technical partners with respect tothe legal requirements relevant to their work Only in a limited number of instances was thesatisfaction of a legal requirement considered to be out of scope In all these cases thiswas due to the fact that the objective of TAS3 is not to develop a final end-product For suchrequirements this was indicated with an NA where normally the WP responsible for therequirement would be indicated

During the WP6 interaction analysis workshop WP6 also identified a number of technicalrequirements which might benefit from some further editing Proposals for changes to thesetecnical requirements were made to the respective WPs WP6 also identified certain re-dundancies (overlap) among the legal requirements and these were resolved by integratingthese requirements into separate new requirements

As a follow-up to the requirements interaction analysis workshop to further promote theintegration of legal requirements with work by the technical WPs WP6 provided each WPindividually with the list of the requirements which are particularly relevant to their work Inother words each WP was presented with a report in which they would only have to look ata subset of the WP6 total requirements list relevant to their technical objectives

A number of additional legal requirements were identified during the workshop Furthersome of the requirements were added to avoid overlapping requirements and better addressthe complexities of the TAS3 project Further some of the requirements were deleted againto avoid overlapping legal requirements The new edited and deleted requirements aredocumented in Section B The final refined list of requirements can be found in the Annex IVof Deliverable 61

246 Validation of Requirements with the Architecture (I8 and I9)

The mapping of requirements to the architecture was repeated after the re-iteration and thecompletion of the interaction analysis There is a danger in viewpoint oriented requirementsanalysis that global requirements are neglected in the process of consolidating the differentviewpoints The global requirements of TAS3 were initially defined by WP2 and were notincluded in the Inter-WP interaction analysis Hence in a preliminary step of the mappingof requirements to the architecture we studied the mapping of global requirements to theTAS3 architecture We defined a template through which we mapped each of the globalrequirements to components in the architecture and identified gaps The results of thismapping is documented in Section 7

Finally once the inter-WP requirements interactions and the legal-technical requirements

Version 20

interactions were completed we validated all of these requirements by mapping them to thearchitecture This activity consisted of reviewing each technical requirement for correspond-ing components in the architecture During this activity gaps in the architecture missingrequirements and overlapping requirements were also identified Further the architectureteam indicated where legal requirements were addressed in the different architecture com-ponents identified gaps in the legal requirements and made suggestions for additional legaland technical requirements

To conclude we produced multiple viewpoints of the requirements of TAS3 These view-points we used to scrutinize our requirements [4] discover discrepancies between under-standings of the different WPs their responsibilities and interactions and most importantlyto identify the requirements that demand extra communication among the partners Throughthese interaction analyses activities we consolidated the different WP viewpoints and the ar-chitecture and finalized our technical legal and application domain requirements

25 Structure of the Document

The remainder of this document is organized as follows We first define the overall objectiveof the TAS3 project and state the objectives of each of the work packages with respect to thescope TAS3 in Section 3 Next we analyze the requirements interactions within each workpackage in Section 4 (see Appendix C and B for the requirements themselves) Followingwe analyze the interaction of the requirements among the different work packages in Sec-tion 5 This is followed by the results of the analysis of the interaction of legal and technicalrequirements in Secion 6 In Section 7 we map the global requirements and in Section 8 wemap the WP technical requirements to the architecture and show which components willfulfill them The inter-WP interaction analysis sections each include also references to gapsand assigns WPs to these where possible In Section 9 we list existing solutions and therequirements that they fulfill as well as an overview of the justifications for selecting specificsolutions for the project A detailed description of all the solutions that were candidates foruse in TAS3 are listed in Appendix D In Section 10 we list the necessary steps to closethe gap between those requirements that can be fulfilled using existing technology and re-search and those requirements that require further research and development and shouldbe fulfilled within the TAS3 project Last in the Conclusion we summarize our findings anddiscuss plans for the next iteration of the Deliverable 12

Version 20

Part I

Deliverable 12 RequirementsAssessment Report

Version 20

3 Objectives of TAS3 revisitedTodayrsquos globalized and interdependent economy is supported by distributed information

systems and dispersed business functions and workforces Society is changing fast as aresult of fluctuating labor markets with shorter term contracts and increasing mobility Theconcept of developing technologies according to the requirements of a specific environmentndash its application domain ndash is more important than ever and yet a greater challenge than everPreviously a technology was defined to work in a specific environment Now the increasedpace of change in technologies as well as in the environments in which those technologiesare embedded requires an iterative and collaborative development process Such processeshave to consider both such changes from the beginning

As a consequence of the increasing dependence of business and personal transactionson service-oriented technology a key exigency for networks and service platforms is to bemade trustworthy According to the ICT Work Programme 2009-101 of the European Com-mission a trustworthy system is qualified as being rdquosecure reliable and resilient to attacksand operational failures guaranteeing quality of service protecting user data ensuring pri-vacy and providing usable and trusted tools to support the user in security managementrdquoAll the above aspects of trustworthiness are relevant in TAS3 and find their place in thecomposing WPs

Each of the above topics relies on a body of work that is surveyed in [25] A key innovationin TAS3 is the holistic approach that is taken The approach combines trust concerns that aretraditionally addressed within separate contexts in a unifying framework Thus for instancebecause we take a user-centric approach we need to consider access control mechanismsand functional compliance trust and usability aspects together

The key interacting parts of the TAS3 ecosystem are technology law and policy Thereforeit is the objective of this document to start with the overall goal of the TAS3 to develop asecure and trusted ecosystem and to refine that goal for each of the workpackages Theaim of this process is to document the interaction of the technical legal and applicationrequirements that make up such an interdependent ecosystem

The overall objective of TAS3 is defined in the Description of Work as follows

The overall objective of the TAS3 project is to specify a trusted services networkthat advances the current state of the art of isolated solutions These solutionsare to respond to the challenges listed in the Description of Work The scientificand technological objective of the project is to research and develop (1) a genericand fully published trusted architecture for securely shared personal data ser-vices and (2) a full implementation thereof using adaptable business processes

In the following we refine the objective of TAS3 shortly summarized above for each of theworkpackages The objective of each work package is articulated with respect to the scopeof the project also as they are defined in the Scenarios in Deliverable 14 [22] For each workpackage we also describe related solved and unsolved problems in the field of trust andsecurity in service-oriented open and distributed environments In some work packages thescope of the research and development questions are different ie WP9 WP10 WP12

1ftpftpcordiseuropaeupubfp7ictdocsict-wp-2009-10enpdf

Version 20

The demonstrators have to address how to set up pilots so that they can link applicationdomains to the TAS3 architecture such that they can test the feasibility of using TAS3 inthose domains and elaborate new requirements to be addressed by the TAS3 WP10 isconcerned with the development of automated validation testing while WP12 is concernedwith integration activities Hence for these work packages the unsolved problems specificto their WP objectives are described

31 Objectives of WP2

WP2 is made up of two teams the Architecture Team and the VUB based team working onontologies The Architecture team which is part of the WP2 has the objectives to norma-tively specify what it means to be TAS3 compliant to the extent that the compliance can betechnically specified WP2 also has the objectives to describe technology in sufficient detailfor a diligent implementer of ordinary skill possibly even an implementer not participatingin the TAS3 consortium to be able to implement the components of TAS3 such that theyinteroperate and to configure the components into a working system that is TAS3 compli-ant The architecture will provide a framework and articulation that allows TAS3 researchtopics to interrelate communicate Ultimately it will provide useful modules that integrateinto a common whole that is TAS3 compliant Last the architecture will satisfy general TAS3

requirements as well as those requirements defined in this deliverable and Deliverable 14[22] that are necessary to a complete secure and feasible system

The objective of the VUB team whose activities are also within the scope of WP2 is todevelop an ontology on Security Privacy and Trust for interoperability The role of this ontol-ogy is to provide semantics that can then be attached (through annotations) to web servicesand business processes Although several ontologies on security have been developed (egNRL Security Ontology [1]) none of these have been developed on the basis of IT securitystandards (eg ISO standards) We believe that such standards provide a terminology andconceptualisation which has been agreed upon by domain experts Furthermore none ofthese ontologies have included the aspect of Trust and Privacy within their framework

WP3 will provide a secure and flexible platform for business processes by developing process-oriented security concepts and an integrated model-driven approach to process manage-ment involving both modelling and execution WP3 will build on a stable modelling andexecution framework of business processes in a service-oriented environment

TAS3 applications are based on executing business processes like the given exampleprocesses of APL or Mass-Layoff scenario [22] Human actors such as coaches or em-ployment candidates are involved in the process The process cooperates with changingsubprocesses (such as the selection of employability providers adequate to the candidatesreputation or rank) or services (which provide access to shared personal data eg certifi-cates of a candidate in the APL scenario) We will provide security concepts model ele-ments and runtime enforcement mechanisms to support business processes that processpersonally-identifiable information in a privacy-preserving way Further we will provide con-cepts and mechanisms which support altering and adapting the schemas of running process

Version 20

instances These mechanisms will take into account properties of the process itself and ofthe available infrastructure eg data involved in the process privacy requirements of theuser quality requirements on the the outcome of the process Thus processes will leveragethe flexibility and openness of the TAS3 architecture while staying secure

In order to provide interoperability within the TAS3 architectures ontologies will semanti-cally underpin the specifications of business processes including their security propertiesand requirements

Business Process Management in service-oriented environments is well supported bystandards in this area A standardized modelling language is given by BPMN execution ofbusiness processes with web services are handled in a standardized way by BPEL (Busi-ness Process Execution Language (see D11 [25]) There exist first implementations of suchbusiness process management systems mostly vendor-specific but also a few open-sourcesolutions

Secure processes are still beyond the state-of-the art Distinct standards in the web ser-vice area exist like WS-Security WS-Trust etc (see D11 [25]) but these are only for se-curing web services to a limited degree Process security is not yet available in a sufficientmanner (see for more details D11 [25] and D31 [23]) TAS3 will support business processesin an open agile application environment that requires flexible and adaptable processes in achallenging manner In particular using security issues to guide and support adaptations ofprocesses is a novel and promising approach Modeling of business processes as meansto capture security rules at the business level and deriving policies for the enforcement levelis not yet sufficiently supported by existing tools Model-driven-development as a generalapproach in software development will be applicable to tackle these issues Adaptation ofprocesses is a vivid research area but existing solutions only provide preliminary solutionsSome research approaches based on specialized theoretical process modelling languageswith proprietary prototype systems exists but these are mostly not for processes in service-oriented architectures Overall the TAS3 architecture will be the first to provide a coherentsolution for the security adaptability and semantic interoperability requirements of businessprocesses

The objective of WP4 is to propose the mechanisms that are necessary to successfullyguarantee that information can be processed in a secure fashion that provides end-to-endsecurity and end-to-end trustworthiness of the whole information processing process Theseobjectives will be achieved through the introduction of information containers with sticky poli-cies that are stored in an authoritative repository that commit to enforcing these policies Wewill also introduce audit and logging functions in order to enable oversight and recognizebreaches of policies Further mechanisms to map and identify information containers poli-cies services service consumers will support the objectives of the work package Userswill be supported in making decisions with respect to revealing their person information totrusted parties through mechanisms to discover service providers that meet and commit toadhere to privacy policies

WP4 addresses the gap in research and development in existing service discovery mech-anisms These often only allow users to discover the functionality of potential serviceproviders but do not take into account their trustworthiness or their ability to commit to

Version 20

enforce certain policies (eg authorization and obligations) Currently existing service ori-ented architectures are not able to deal with privacy enhanced identifier mappings We willattend to these open problems in the activities of Work Package 4

The objective of WP5 is to create an expressive flexible Trust Management (TM) frameworkwhich leads to the following concrete objectives (1) define a flexible TM architecture (2)create an efficient TM policy evaluation engine (3) provide Trust feedback mechanismsbased on the evaluation of behavior policy compliance and key performance indicators

Services in the employability and eHealth setting rely heavily on personally identifiableinformation To build user trust in such services it must be possible for the users to selectfrom a wide range of trust policies Usersrsquo trust can be based on the credential presentedby an entity on the past performance of the entity Existing TM systems can be divided intotwo main categories structural and behavioral Credential based Trust Management (CTM)is a structural rule based approach to managing authorization in environments where au-thority emanates from multiple sources Session Trust Management (STM) which fits withinthe CTM setting is an approach to dynamically manage authentication in distributed envi-ronments where users may be authenticated by different mechanisms at different IdentityProviders Reputation Trust Management (RTM) is an approach to manage and dynami-cally update reputations based on the behavior of participants Key Performance Indicatorsbased Trust Management (KPITM) capture past behavior and can be used to build a novelbehavioral trust metric However no existing framework combines these categories of TMsystems

Our aim is to create a trust policy framework within the TAS3 architecture which is able toefficiently enforce a broad range of trust policies by combining CTM STM RTM and KPITMbased trust metrics As a basis for supporting structural trust we propose to use TuLiP [13]This framework is flexible and provides guarantees for credential chain discovery one ofthe main issues in this domain Though the system provides a sound basis open issuesexist ranging from technical eg the support for standardized attribute credential formats tofoundational eg delegation control what does delegating a decision imply As a basis forsupporting behavioral trust we propose to use computation of centrality measures within adatabase setting such as the Oracle database Centrality measures [28 16 19 20 24] aregraph algorithms which can be used to find the most trustworthy participants based on thefeedback [17 29] What is missing is a flexible framework which allows the user to selecttheir preferred metric We plan to create this by defining an algebraic language with supportfor centrality measures along with methods to evaluate this on a database of feedback data

The objective of Work Package 6 is to enable trust through developing a contractual in-frastructure that supports and binds technology platforms with organizational policies anddefines supports and binds organizational as well as individual obligations The contractualframework is designed to meet or exceed requirements of the relevant privacy and sectorallaws The Framework will be composed of Infrastructure or ecosystem level requirements

Version 20

as well as requirements at the individual and transaction level The latter will be dividedbetween service providers with a direct relationship to the individual and those that onlyinteract with other service providers

The need to enable trust requires that individuals have faith in their service providers toproperly manage and secure their information Previous attempts to do this purely in technol-ogy P3P EPAL have met with limited success and provided limited scope solutions Purelycontractual solutions have likewise met with limited success at the individual level becauseof the difficulty in understanding legal drafting On the business side todays more global in-frastructures make maintaining complex contractual infrastructures and ever increasing anduntenable burden These problems remain at best partially addressed in both the contractand technology realms

The TAS3 infrastructure addresses these problems by collaboratively developing con-tracts policies and technology and allowing them to interface in a manner that is designedto be mutually supportive This collaborative development model which reaches down tocontractually enabling sticky policies provides a significant evolution in both contractualand technology development models It must be recognized that this level of interdepen-dence and planning at the design stage increases complexity and burden of developmentbut should yield significant benefits in operation and compliance Furthermore this collabo-rative model enables requirements needed for legal compliance to be prebuilt into technol-ogy (audit trails etc) while addressing limitation of some technical implementations in policyand contract These are the solution basis of work package six which will be elaborated inthe contractual frameworks

The overall objective of WP7 is to build a fully dynamic privacy preserving authorizationinfrastructure that allows credentials to be dynamically created revoked delegated and ag-gregated as necessary between users administrators and processes This infrastructureshould be easy to use for service oriented applications in order to achieve wide deploymentof the TAS3 architecture The infrastructure should enable the dynamic management and up-date of authorization and privacy policies It is our goal to incorporate sophisticated real-lifeauthorization requirements such as Break the Glass policies dynamic separation of dutiesstate based decision making resolution of conflicting policies and adaptive audit controlsAnd last but not least WP7 wishes to contribute to international standards development inthe area of IdM and authorization protocols and profiles and authorization ontology

Partial solutions exist in the field of service oriented authorization For example SAMLallows short lived credentials to be dynamically created but does not support long lived cre-dentials or revocation PERMIS supports credential aggregation but only when the userhas the same name at the different credential issuing sites PERMIS SAML and X509 sup-port credential delegation but not in a privacy preserving manner PERMIS supports statebased decision making and separation of duties but the policy language is not standardizedNone of the solutions above have implemented the Break the Glass policies in an applicationindependent manner

Many papers have been published on dynamic delegation of authority between users andprocesses [2 3 7 9 11] but no open source software currently exists that provides thisgeneral purpose functionality for service oriented architectures Further a standardized lan-

Version 20

guage for expressing obligation policies is still lacking and no general purpose obligationenforcement infrastructure exists There is no recognized model architecture or infrastruc-ture for the support of sticky policies This includes the lack of a standard protocol for passingpolicies to PDPs along with authorization decision requests Such a standard is necessaryto enforce sticky policies an important stepping stone for implementing an authorizationinfrastructure that enables flexible and easy implementation of data protection obligations

The main objective of WP8 is to provide a uniform interface to allow service providers andservice requesters to access TAS3 in a standardized manner WP8 builds the gatewaysfor applications like business process engines web front-ends or repositories to access theTAS3 infrastructure We also deliver the base components for the pilots so that they canconnect to TAS3 and exchange information in a TAS3 secured and trusted way This alsomeans that our two gateway services on service requester and on service provider side needto be TAS3 aware and hence they also have to cope with authentication and authorizationprotocols Those gateways will not only route things from one side to the other They will alstransform aggregate and disaggregate the sent payload and attached policies

In the first iteration or phase of TAS3 the interface will be experimental Later on welldivide this component in an application dependent and application independent part (WP7is working on the application independent part of the Requester and Responder PEP) Theapplication dependent part is necessary to support special classes of applications (BPELengines Repositories) This gateway will be provided as web service because the wholeTAS3 infrastructure is based on the SOA (Service Oriented Architecture) approach Besidethose mentioned gateways Risaris (partner in WP8) will extend and adapt their SOA gate-way to allow legacy systems (especially legacy databases) to be integrated in TAS3 Bythat it will be possible to access also older datasets

Another task in Work Package 8 is the adaptation of a repository so that it can handleperson related data This is something new in the world of repositories because normallyrepositories store digital assets that belong to the domain of libraries The storage andmodification of person related data brings new requirements to a conventional repositorywhich have to be taken into account and need further implementation and adaptation ofexisting repository functions

The objective of the three demonstrators in Work Package 9 is to prove the generic ap-plicability of the TAS 3 trust infrastructure for exchanging personal information in differentdomains More specifically it is the objective of the pilots to demonstrate the trust securityand privacy services required to deliver major reforms of vocational education and lifelongskills development through partnerships of educationtraining providers and employers andrequired to enable information exchange within eHealth and ensure patient empowermentIn the pilots the TAS 3 infrastructure as a whole and the different components specific toeach pilot will be tested in relation to the needs demands and concerns of both end-usersand the registered service providers

Version 20

Until now personally identifiable information (PII) has been mainly used by and stored onbehalf of corporate institutional and service provider driven processes We are entering aworld however where the emphasis is shifting from organization to the individual and thecontrol of users data is following suit

In general users perception of trust and security of the internet and electronic data ex-change has decreased in recent years Several significant episodes of loss theft and abuseof personal sensitive data in different EU countries (see details in [25] Chapter 132)) havearoused mistrust in users who might otherwise see the benefits of sharing PII in this wayIn Holland 26 (438000 as of March 2009) of citizens have lodged objections to partici-pation in the EPD (Electronic Patient Record) While most opponents do not object to dataexchange per se they do not trust the security of the systems used and consider that theyhave insufficient control over their PII It is to be anticipated that similar issues will arisewith the increasing use of ePortfolios not only to support educational processes but also tosupport lifelong employability See also [25] Chapter 132 Until now there have not beensignificant or successful attempts to resolve the issue of mistrust in security on the use andexchange of employability-related personal data Work Package 9 will benefit from the workof other partners to build a trustworthy and secure infrastructure for the exchange of highlysensitive personal data in employability and healthcare Conversely the other work pack-ages will benefit from the WP09 demonstrations to prove their trust and security solutionsand empower restoration of trust to users and other stakeholders

Work Package 10 aims at ensuring quality and trustworthiness of the handled businessprocesses and of service provision The goal of WP10 is thus to develop and implementa comprehensive validation methodology of the TAS3 platform and its offered services Inparticular WP10 will work towards validating the functional and QoS compliance of servicesthat participate in a TAS3 choreography and will contribute to enhance the trustworthinessof the TAS3 ecosystem with

bull a novel framework for on-line service testing that will be seamless embedded within theTAS3 architecture such a framework will strengthen service registration by a prelimi-nary verification session and will enforce services to abide by their manifested policiesby periodic compliance testing and negativefuzz testing

bull support for verification of compliance to manifested access policies by automatedderivation of XML documents (maybe XACML) from XML Schemas

The fulfilment of the above objectives requires research and development in model-basedautomated testing of service-oriented compositions and in XML-based modelling and trans-formations

From an end-user perspective the objective of WP10 is to develop measures to ensurePerceived Quality and Trustworthiness of the TAS3 platform and its offered services Inparticular

bull Measure usability and trust levels of TAS3 architecture

Version 20

bull Measure perceived quality of service in terms of usability security privacy satisfactionand trust

bull Analyze the influence of previous concepts on the end-user intention to use the sys-tem

bull Measure accessibility levels of TAS3 architecture

The success of any information system architecture must be based not only on technol-ogy schemes standards and protocols but also on usersrsquo perceptions [5] Indeed servicesare used by a wide spectrum of end-users who will probably have a diverse expertise sothat the correct measurement of end-user perceptions has acquired a great relevance in thiscontext Thus in order to convince end-users to use a given infrastructure their perceptionsregarding ease of use trust and performance must be taken into proper account [12] Alsothe capability to easily access services becomes important for trustworthiness [14] Broadlyspeaking in any service-oriented applications also in the eHealth and in the employabil-ity context the provided services must be developed according to the user perspective [6]However to date most of research on quality of service and trust is technologically orientedIt is at this point where Unizar contribution to WP 10 becomes especially relevant In par-ticular Unizar can provide TAS3 a non-technical approach that is specific methodologiesto measure end-users perceptions (usability service quality and global trust perceptions)as well as understanding precursory factors and outcomes of all these aspects As a re-sult it will be possible to establish guidelines in order to increase the levels of usability andend-users trust Moreover accessibility will be considered as a fundamental requirement ofTAS3

The main objective of WP12 is to assure that there will be a coherent end result of all thedevelopment work instead of ten incompatible mini systems Specifically it is the objectiveof WP12 to ensure that all developed software modules and all work performed by WP110maintain a close fit and integrate with the overall TAS3 project WP12 activities will also de-fine document implement and manage interfaces between the core technical modules (ietrust layer WP3-7 application layer WP8) integrate the trust layer with the employabilityand eHealth application layers (WP89) and test the TAS3 system as a whole on functionalityperformance and manageability usability and effectiveness and adaptivity

It follows that WP12 is not a design or development work package As such it doesnot bring core components models interfaces architectures or prototypes to the projectThese tasks are in the scope of WP1 ndash WP10

A major activity to assure coherence is that the primary WP12 contributors thoroughlystudy nearly all components and the complete system This is an underground task whichdoes not lead to any visible deliverable so it is very unrewarding A good understandingallows WP12 management to question and direct the contributions for easier and betterintegration This is one of the major reasons to have both Architecture and Integration underthe same cluster lead At the same time it allows WP12 to keep a close eye on the properdocumentation of interfaces requirements components and test beds It is expected thatWP12 needs to monitor the central issue registration as well and even moderate it and

Version 20

assure proper feedback to and from developers When demonstrators come online WP12will be the core WP to bridge the gap between the demonstration and a loose collection ofsecurity components

Version 20

4 Requirements interaction in TAS3 Work PackagesIn this Section we do an analysis of the requirements from each of the work packages

As we mentioned in the Introduction we sent a template out to the TAS3 partners in whichwe asked them to also provide us with a refined set of requirements for their activities intheir work packages These requirements are now listed in Appendix C The requirementstemplate is in Appendix A Specifically we will analyze the interactions among the work pack-ages requirements in order to partition the requirements into related clusters determine therequirements of higher priority and to become aware of singular requirements and possiblemissing interactions or requirements We have asked all partners to do interaction analysiswhen they elaborated their work package requirements

We visualize the requirements interactions using directed graphs Further we denote theresponsible teams for each of the requirements We do the latter by drawing circles labeledwith the name of the team around the requirements that belong to each team in the workpackage In case there is only one team in the work package we label the circle simply withthe number of the work package

The interactions between the requirements are denoted on the edges of the graph Thelabels of the edges denote the kind of interaction source requirement depends on target re-quirement is denoted with a D where the head of the arrow points to the target requirementFurther labels using the same reading direction are S for supports I for implements A forabstracts and C for conflicts with We especially wanted partners to articulate possible con-flicts since we see them as a way of discovering either under-specification communicationneeds or improved design needs

When we received the interaction analysis results we did notice different interpretationsof our controlled vocabulary That a requirement A supports another requirement B didnot always mean that B is dependent on A Therefore supports was sometimes used inthe sense of rdquostrengthensrdquo rather than rdquois a condition forrdquo Further a requirement couldimplement many other requirements or a requirement could abstract many implementingrequirements We will integrate this knowledge into the next iteration of the Deliverable 12For now this means that the interactions between the requirements are not bi-directionaleg supports does not imply depends and vice versa

41 Requirements Interaction in WP3

The analysis of requirements interaction shows that one of the main requirements of WP3is to make it possible for process designers to specify the assignment of tasks to actors in abusiness process in a sufficiently abstract flexible and secure way using roles for groupingtasks and responsibilities (D12-35) which is implemented by the requirement D12-36which states that business process providers (in general coordinators of a complex service)must be able to control who performs a task by binding authorization to perform a taskand access necessary resources to roles D12-36 also implements the tools to define(graphical) models of their business processes including the interactions of the process withexternal components ie web services and human activities (web interfaces) and otherbusiness processes (D12-31)

Another requirement which is important for WP3 activities is about the recovery of busi-

Version 20

WP3 35

312313

WP7 WP10

Figure 41 WP3 requirements interaction

ness processes from error situations (D12-39) The errors that may be generated by thesecurity requirements such as authorization for tasks (D12-36) mutual exclusion betweenroles (D12-38) and user access control on PII including service provider compliance withit (D2-311) need to be handled properly and hence depend on D12-39 The fulfillment ofthis requirement also depends on interactions with the requirements of WP10

Further dependencies exist between the requirements in order to provide secure (D12-315) adaptable processes (D12-313) and the requirements for business processes to re-ceive interoperability information with respect to services and business processes as wellas privacy policies of other service providers (D12-312) The latter is also dependent onthe ability of users to specify on which of their PII the process should have access and theservice providers abilities to discover for a particular piece of PII which user settings applyand whether the PII is particularly sensitive (D12-311)

Further interactions of the WP3 requirements with the requirements of other WPs is ana-lyzed in Section 5

According to the interaction analysis the possibility to demonstrate to lay users the com-plex security and trust features of the TAS3 (D12-43) and the ability of providers to provethat they processed the information and services in accordance to the required policies(D12-44) are the two central high-level requirements of the work package These two re-quirements depend on all the other requirements in the work package

Most central with respect to dependencies are the requirement to make the discoveryservice and policy management system user friendly and easy to configure and use (D12-

Version 20

48) and the requirement to take trust and reputation scores of both service consumersand providers into account in the discovery service (D12-49) Since so many of the otherrequirements and the two high-level requirements depend on these two requirements theyshould be prioritized in the WP

D12-49 supports the trust management system in WP5 while the requirement on accessunder exceptional situations (D12-46) interacts with the requirements of the break the glassfunctionality as implemented by WP7 Further interactions of the work package are definedin the inter-WP requirements interaction analysis in Section 5

The requirements of WP5 are strongly interdependent see also Figure 43 RequirementD12-51 is the higher level requirement that states that the trust management system shallanswer to trust policy evaluation requests which can use different sources of trust Mostother requirements support D12-51 or are refinements thereof User authentication is alsoa central requirement which is a pre-condition for the fulfillment of all the WP5 requirementsThe development and implementation of secure and privacy preserving user authenticationwithin the TAS3 architecture is the responsibility of WP7 Hence WP5 has a strong depen-dency on WP7 and the authentication solution they provide

Another important requirement is D12-53 which describes the need for a reputationbased trust management system This is supported with requirements regarding business

Version 20

5251 D

Version 20

processes that provide trust feedback opportunities (D12-55) support for gathering repu-tation feedback (D12-54) and legalcontractual models to support the feedbacks and rec-ommendations of the trust management system

The work package has two other requirements which have dependencies on the require-ments of other work packages Specifically the fulfillment of D12-59 which is about trustpolicy formulation support depends on the research and development activities in WP7Requirement D12-55 on trust feedback opportunities within the business processes willdepend on activities of WP3 and the domain specific needs of the demonstrators in WP9The detailed relationships between those requirements and the requirements in WP7 andWP9 will be presented in Section 5

WP6 requirements are divided into three sections Intake Legal Requirements and ContractFraemwork

bull D12-61 ndash 62 are the intake and qualification requirements these are the processesfor qualifyingverifying prospective users and screeningvalidating service providers toassess their ability to comply

bull D12-63 ndash 612 are the basic legal requirements that either emanate from the DataProtection Directive or a needed to give effect to those requirements (complaint han-dling compliance etc)

bull D12-613 ndash 617 are those sections that provide for or give effect to aspects of thecontractual and policy framework

The Intake processes are needed to assure that individuals are validated in the architec-ture and there is a mechaism to provide them with notices and an opportunity to developtheir privacy polices and exercise choices In this aspect the intake process will work inconjunction with the user interface The organizational or service provider intake processis of a more rigorous nature and goes beyond just idetifying organizations to the systembut rather assists in qualifying their ability to comply Both of these elements are necessarypredicate functions to assure that both legal requirements will be complied with and that thecontract framework will be honored

The requirements of the Directive are interlinked and both support and depend on eachother by defintion All the bidirectional edges in Figure 44 stand for this interdependencyand are not labeled for readability reasons

When data is going to be collected then data subjects need to consent (D12-66 D12-67) to the data that is going to be collected The consent is usually limited to the use of thedata for a specific purpose (D12-65) The collected data should not be more then neces-sary to complete the business function (D12-64) This all needs to be enveloped in a notice(D12-63) Further audits will be put in place so that activities that are not compliant withrespect to the collected data can be captured (D12-69) the necessary redress processescan be put into place (D12-610) An underlying helping mechanism here enables the usersto make requests for access (D12-8)

Version 20

611 612S

The notice requirement (D12-63) together with the Intake Process requirements throughwhich all users (D12-61) and organizations (D12-62) are identified are overarching re-quirements that depend on and support all other requirements for data protection and legalcompliance to be executed All of these requirements are supported through two horizontalsecurity requirements with regard to confidentiality integrity and availability of data(D12-611 D12-12)

The legal requirements as identified above while madated by law need to be made op-erational TAS3 has tried to create an innovative development model by coordinating andintegrating the development of technology policy and contract All three elements play arole in compliance with the identified legal requirements The policies help define minimumpractices that service providers will comply with and the contractual framework will bind allthe parties to their obligations and enable individual rights

A focal point of this compliance is thus the execution of the contract creating the binding(D12-613) The contract requires the use of TAS3 technology (D12-614) and acceptablepolicies (D12-615) and evidences the acceptance of the agreement to be bound in general(D12-616) and pursuant to technical elements and process (D12-617)

The legal and Contract Framework requirements interact with all the other work packagesof the TAS3 project These interactions will be picked up later in Section 5 Futher therequirements for WP6 have been refined after the completion of this deliverable Theserefinements can be found now in D14 [22] under the legal requirements in Section 6 Wewill integrate these changes in the next iteration of this deliverable

Version 20

720719

725724

Most of the activities in WP7 are focused on the authorisation of user activities (D12-76)in TAS3 based on trust and privacy policies There are many dependencies among the re-quirements that implement the authorisation The ability for users to delegate activities toother users (D12-71) and comparably the ability of service providers to delegate activitiesto other service providers (D12-714) depend on the feasibility of revoking the delegationcredentials (D12-79) In order to be able to pull user credentials on demand (D12-712)depends on the ability of the service providers to locate those credentials (D12-713) Thisprocess is further supported by the ability of users to push credentials to the system dynam-ically (D12-715)

Implementing audits is part of WP7rsquos activities The audits need to be adaptive to changesin the system (D12-725) which depends on the secure implementation of the authorisationaudits (D12-724) The authorisation system will also implement a break the glass policy(D12-722) that requires the authorisation system to make decisions based on the currentstate of the application or system (D12-723)

Users must be able to provide consent for the use of his private data and credentials inTAS3 (D12-726) In order to achieve this the user must be able to dynamically set hisherprivacy policies (D12-77) which depends on the service providers being able to updatetheir policies dynamically without having to bring down their systems (D12-719)

User in TAS3 should be able to use different pseudonyms in order to protect their privacy(D12-716) and each of these pseudonyms should be implemented such that it should bepossible for users to prove who she is to any service provider (D12-73) The opposite the

Version 20

authentication of the service provider (D12-73) to the user and other service providers isalso a requirement of WP7

The work package members have also noted a potential conflict between two require-ments The first requirement states that service providers should not be able to link togetherthe sequential requests of a user without the users consent (D12-718) When there is aconsent the requirement may conflict with another requirement which states that differentservice providers should not be able to collude together to determine who a pseudonymoususer is without the users consent (D12-78)

The authorisation mechanisms developed by WP4 are central to TAS3 There is also aclose interaction between the trust management system provided by WP5 and the require-ments of WP7 The detailed relationships between those requirements and the requirementsin WP5 and other related WPs will be presented in Section 5

Figure 46 WP 8 requirements interaction

The central requirement for WP8 is to build a gateway for the demonstrators to be able toaccess TAS3 (D12-81) All further requirements depend on this specification of the gateway

These other requirements are as follows on the legacy side there is a requirement for aninterface so that legacy databases can provide their data and service to TAS3 (D12-82) Onthe user side the requirements are to allow end users to access TAS3 functionality througha business process (D12-83) and through a generic client (D12-84) to make it possiblefor end-users to access and manage their policies (D12-85) and to store and modify their

Version 20

data stored in repositories in TAS3The WP8 will support requirements of WP9 while it will also depend on their require-

ments The business process related requirements will require interaction with WP3 Thedetailed relationships between those requirements and the requirements in WP9 and anyother related work packages will be presented in Section 5

WP8WP4

The main requirements of WP9 are focused on the needs of the user and the protection ofhisher data The demonstrators will make use of TAS3 to make sure that processes used inthe demonstrators have secure access to data drawn from a variety of distributed sourcesand are only be able to access the specific data they need (D12-91) They will make useof the TAS3 architecture to enable users to set view control and change policies for theirdata at a variety of levels down to the lowest (field) level from accepting clearly-formulatedpreset policies to adding fine-grained policies to specific sets of data the users must clearlyunderstand the implications of this policy choice (D12-92)

Further users have to be securely authenticated and authorised before any access todata is allowed (D12-94) and the access to the system must be easy without the needfor overly complex authentication and authorization processes (D12-93) And in line withdata protection measures the demonstrators will require a secure and reliable audit trailshowing who accessed user PII when and for what purpose and whether any changes were

Version 20

made (D12-95) All other requirements of the work package support or depend on theserequirements The detailed relationships between these requirements and the requirementsin WP8 or other related work packages will be presented in Section 5

WP 10 is made up of two groups whose requirements are not interdependent For UNIZARall the requirements are related to user evaluation of different quality aspects of the TAS3

architecture Since they need an interface to do the user studies they are dependent on theuser interfaces that will be developed by the demonstrators in WP 9 In further refinementsof the requirements it is possible that UNIZAR delivers specific requirements to WP9 withrespect to building testable interfaces and vice versa Changes made to the interfaces of theWP9 are likely to effect the user tests executed by UNIZAR and need to be communicated

The requirements of the CNR team have internal dependencies An analysis of the depen-dencies shows that the accompaniment of services that are to participate in a TAS3 chore-ography with models describing their characteristics (D12-108) is of greatest importanceAll other CNR requirements except D12-103 depend on D12-108 It is important to notethat the fulfillment of requirement D12-108 itself depends on the rest of the TAS3 WPsAnother dependency is between the requirement for identifiable error messages (D12-103)and other TAS3 work packages with a strong interaction with WP2

An analysis of inter-WP requirements interaction will reveal the exact requirements inter-action between the requirements of WP10 and the requirements of other work packages

49 Requirements Interaction in WP 12

The WP12 is responsible for the integration of the TAS3 architecture work packages Henceit is a requirement to provide all project partners with a single central place where all knownissues and defects of all components are administrated (D12-1223) and where all devel-opers testers and users can test and understand signicant parts of the complete systemat least at the conceptual level (D12-121) This also means that change management willhave to be enforced on core integration resources (D12-1221) Requirements D12-21 andD12-223 have to be balanced out with the needs of participants to choose when and howto perform their contractual duties (D12-123) In cases of conflict and important andorurgent events there will be a hierarchical escalation to raise these to organisational levelsabove non-responsive ones (D12-124)

In order to support the integration objectives all developers testers and users must haveaccess to all project documentation regardless of origin target audience or assumed rel-evance (D12-122) All participants must also check released components for correct oper-ation in the network environment and developers must be kept up to date as of the perfor-mance of their released component All other requirements of WP12 support or depend onthese requirements

The WP interacts with all other work packages hence we have left out the interaction ofthe requirements with other work packages

Version 20

UNIZAR

108102

107 106

121 1214

1211 1210

12301229

12281227 D

Version 20

5 Inter-Work Package Technical Requirements In-teractions

It is our objective to complete interaction analysis so that we can consolidate the view-points of the WPs and check for completeness with respect to the global requirementslegal requirements and the architecture The analysis maps out the interdependencies be-tween the work packages and hence helps to find the inconsistencies between the WPrequirements viewpoints This chapter provides an overview of the activities that technicalWPs completed with respect to the interaction of the technical requirements Later in Chap-ter we present the results of the analysis of legal and technical requirements interactionand the final mapping of legal and technical requirements to the architecture

We completed the following activities for inter-WP technical requirements interaction anal-ysis (the number refer to the overview of interaction analysis activities depicted in Figure 21

Elicit inter-WP requirements interactions (I2) for the inter-WP requirement interactionanalysis we asked each WP to complete Template 2 in Appendix A The results wereincluded in the first iteration of D12 we have now moved them to Appendix E

Map WP requirements to architecture (I3 and I4) we mapped all the technical and le-gal requirements to the architecture and captured inconsistencies The results of thisfirst mapping are now in Appendix E

Reiteration of inter-WP requirements interactions (I5) we used the first iteration of theinter-WP requirements interaction and mapping of requirements to the architectureas input for the second iteration of the inter-WP requirements interaction analysisWe started with the analysis of requirements that were indicated as being rdquosimilarrdquoand asked WP partners to communicate with each other to determine whether thesimilarity is due to a requirements overlap or due to differences that were not clearfrom the formulation of the requirement The details of this activity are described inSection 51 We then updated the requirements list according to the results of thesimilarity analysis We also updated the legal and technical requirements list after there-iteration of the requirements elaboration We then asked the partners to re-iteratethe requirements interaction analysis We then analyzed the results for inconsistencycandidates and these were then discussed and resolved during a workshop with allpartners The details of these activities are in Section 52

51 Similarity Analysis

In order to complete the similarity analysis we first used the DOT language to represent theinteractions between the requirements These are in the following format

ldquoRequirement 1rdquorarr ldquoRequirement 2rdquo [label = ldquoType of interactionrdquo]

We call lsquoRequirement 1rsquo the source and lsquoRequirement 2rsquo the target requirement The inter-action is indicated by the owner of Requirement 1 ie the WP from which the requirementoriginates Below is the DOT format representation of the similarities identified during thefirst iteration of the Inter-WP requirements interaction analysis

Version 20

ldquoD12-312rdquorarr ldquoD12-214rdquo [label = ldquoSimrdquo]ldquoD12-911rdquorarr ldquoD12-223rdquo [label= ldquoSimrdquo]ldquoD12-312rdquorarr ldquoD12-223rdquo [label = ldquoSimrdquo]ldquoD12-98rdquorarr ldquoD12-222rdquo [label= ldquoSimrdquo]ldquoD12-913rdquorarr ldquoD12-218rdquo [label= ldquoSimrdquo]ldquoD12-913rdquorarr ldquoD12-219rdquo [label= ldquoSimrdquo]ldquoD12-510rdquorarr ldquoD12-34rdquo [label = ldquoSimrdquo]ldquoD12-312rdquorarr ldquoD12-47rdquo [label = ldquoSimrdquo]ldquoD12-94rdquorarr ldquoD12-510rdquo [label= ldquoSimrdquo]ldquoD12-97rdquorarr ldquoD12-68rdquo [label= ldquoSimrdquo]ldquoD12-98rdquorarr ldquoD12-68rdquo [label= ldquoSimrdquo]ldquoD12-93rdquorarr ldquoD12-75rdquo [label= ldquoSimrdquo]ldquoD12-510rdquorarr ldquoD12-73rdquo [label = ldquoSimrdquo]ldquoD12-94rdquorarr ldquoD12-73rdquo [label= ldquoSimrdquo]ldquoD12-94rdquorarr ldquoD12-76rdquo [label= ldquoSimrdquo]ldquoD12-99rdquorarr ldquoD12-77rdquo [label= ldquoSimrdquo]ldquoD12-98rdquorarr ldquoD12-711rdquo [label= ldquoSimrdquo]ldquoD12-95rdquorarr ldquoD12-724rdquo [label= ldquoSimrdquo]ldquoD12-92rdquorarr ldquoD12-85rdquo [label= ldquoSimrdquo]ldquoD12-97rdquorarr ldquoD12-86rdquo [label= ldquoSimrdquo]ldquoD12-311rdquorarr ldquoD12-85rdquo [label = ldquoSimrdquo]ldquoD12-311rdquorarr ldquoD12-96rdquo [label = ldquoSimrdquo]ldquoD12-510rdquorarr ldquoD12-912rdquo [label = ldquoSimrdquo]ldquoD12-910rdquorarr ldquoD12-33rdquo [label= ldquoSimrdquo]ldquoD12-910rdquorarr ldquoD12-48rdquo [label= ldquoSimrdquo]ldquoD12-910rdquorarr ldquoD12-84rdquo [label= ldquoSimrdquo]ldquoD12-913rdquorarr ldquoD12-76rdquo [label= ldquoSimrdquo]

In order to resolve these similarities we took the following steps

Step 1 ask the owner of the target requirement to state whether they agree with the simi-larity between the two requirements

Step 2 If the owner of the target requirement agreed then the two requirements are de-clared redundant and one of the requirements is deleted If no agreement is availablethen the owner of the target requirement is asked to propose changes they foundnecessary to avoid the redundancy The partners could also indicate if they had ajustification for the redundancy

Step 3 ask the owner of the source requirement to validate the proposed solution

Once these four steps were concluded we updated the requirement set with their con-clusions and the second iteration of the requirements elaboration Then the partners wereasked to re-iterate the interaction analysis The results of the second iteration of the inter-WPinteractions analysis is provided in Appendix F in DOT notation

Version 20

52 Inconsistency Analysis

Once the second iteration of the requirements interaction analysis was completed we usedour inconsistency detection tool to look for inconsistency candidates due to the patternsdescribed in Section 2 Figure 51 provides a screenshot of one round of results from theinconsistency detection tool The figure shows homogenous interaction cycles with the re-lationship type ldquosupportrdquo The existence of multiple edges between two nodes indicates thatthere are multiple support cycles During the requirements interaction workshop all partnersanalyzed the set of requirements that produced the cycles and negotiated the re-definitionof the requirements so that the inconsistencies were resolved

Figure 51 A screenshot of the interaction graph with inconsistencies as producedby the inconsistency detection tool

Inconsistency resolution consisted of changing the semantics of the requirements to bemore precise merging or splitting requirements and in some cases the deletion of the re-quirements

After each round of negotiation and editing of the requirements and interactions we ranthe inconsistency detection tool again to see if further inconsistencies appeared In ap-proximately three rounds all of the inconsistencies based on the different patterns wereeliminated Once the inconsistency analysis was completed we updated the list of require-ments and presented it to the legal requirements team in WP6 to complete their interactionanalysis

Version 20

6 Legal and Technical Requirements Interaction Anal-ysis

Within the last year the legal requirements were refined by WP6 Once the refinementof the legal requirements were completed we prepared an interaction analysis templateas discussed in Section 2 that was filled out by WP6 Later a workshop was organizedwhere the other WPs discussed with WP6 the interaction of the legal requirements with thetechnical requirements and identified gaps in both sets of requirements The analysis of thegaps often led to immediate updates to the technical and legal requirements in a few of thecases gaps that have to be addressed in the future were captured We document the resultsof the legal and technical requirements interaction analysis in this chapter For the list of thelegal requirements used in the interaction analysis please refer to Annex IV of Deliverable62

Source Re-quirement

Interaction Type Target Requirements

D12-61

is fulfilled byis partially fulfilledby

925 (documentation provisioning)

not fulfilledconflicts withcomments Requires additional work a Complete outline intake

process userdata subject (see also 64 and 65) b En-rollment of users LoA needs to be specified c Pilotsneed to take into account intake process as defined inD62 (tailoring to context might be necessary) d Spec-ification of technical user interface

This requirement will be fulfilled by WPs WP6 (61a) WP7 9 (61b) WP9 (61c) WP2 8 9(61d)

Source Re-quirement

D12-62

108 1012 1013 (documentation provisioning by or-ganization) 109 (verification of technical capacity tocomply)

not fulfilledconflicts withcomments Requires additional work

a Complete outline intake process organization b En-rollment of organizations LoA needs to be specified cPilots need to take into account intake process as de-fined in D62 (tailoring to context might be necessary)d Specification of technical interface for enrolment oforganizations e Technical specifications organizationsmust meet in order to become TAS3 participants

This requirement will be fulfilled by WPs WP6 (62a) WP7 9 (62b) WP9 (62c d) WP2(62e)

Source Re-quirement

Version 20

D12-63D12-631D12-632D12-633

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work (but only for actual deploy-

ment)This requirement will be fulfilled by WPs NASource Re-quirement

D12-64

925 (prior information)

not fulfilledconflicts withcomments Requires additional work a Ensure agreement to use

specified technologies is obtained during intake pro-cess b See also 61d and 62e

This requirement will be fulfilled by WPs WP6 (64a)Source Re-quirement

D12-66D12-661D12-662D12-663D12-664D12-665D12-666

is fulfilled by 41 (enforcement of sticky policies) 45 (policy compli-ance) 924 (immediate effect of changed policies) for661

is partially fulfilledby

925 (prior information - for 66)

not fulfilledconflicts withcomments Requires additional work a Ensure agreement to be

bound by use of specified technologies is obtained dur-ing intake process (66) b Communication and commit-ment to usage directives (sticky policies) even wheninformation exits (663 665) c Non-repudiation ofagreement (662) d Easy accessibility and usabili-tyclarity of policies (664 - 666)

This requirement will be fulfilled by WPs WP6 (66a) WP4 (66b) WP6 2 (66c) WP9 (66d)Source Re-quirement

D12-67

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Overview of policies which

must be implemented b See also 669 with regards toverification of implementation

D12-68

not fulfilledconflicts with

Version 20

commentsThis requirement will be fulfilled by WPs ALLSource Re-quirement

D12-69D12-670D12-672

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Identification of which ac-

tors within the TAS3 network shall assume these tasks(taking into account separation of duties)

This requirement will be fulfilled by WPs WP2 ALL (69a)Source Re-quirement

D12-610

311 (ability to express privacy preferences wrt to whichdata to be used in particular business process) 313(adaptation of business processes in light of privacypreferences) 924 (ability to dynamically set policieswith immediate effect) 92 (ability for user to set pri-vacy preferences for objectsdata and presentation inan understandable manner) 96 (ability for user to setprivacy preferences wrt recipients) 41 (enforcement ofprivacy preferences even when aggregated from dif-ferent sources) 77 (ability to dynamically set privacypolicies) 726 (consent for use of credentials and otherpersonal data)

not fulfilledconflicts withcomments Requires additional work a Specification of how le-

gitimate bases other than consent shall be recognizedand incorporated in authorization decisions

D12-6101

925 (inform user about implications expression privacypreferences)

not fulfilledconflicts withcomments Requires additional work a Specification of how it

shall be ensured that consent is freely given informedand unambiguous

D12-6102

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts with

Version 20

comments Requires additional work a Specification of instancesin which consent in writing is required b Specificationof how requirement of consent in writing shall be satis-fied

This requirement will be fulfilled by WPs WP6 (6102a 6102b)Source Re-quirement

D12-611

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of instances

in which consent cannot be freely given b Specifica-tion of how to accommodate those instances in autho-rization decisions

This requirement will be fulfilled by WPs WP6 (611a) WP7 (611b)Source Re-quirement

D12-613

is fulfilled by D12-311 D12-313 D12-41 D12-77 D12-726D12- 92 D12-96 D12-924

is partially fulfilledbynot fulfilledconflicts withcomments

This requirement will be fulfilled by WPsSource Re-quirement

D12-614

220 (only authorized disclosures and actions) 76 (au-thorization required for any action) 41 (enforcement ofuser-centric policies on aggregated information sets)77 (ability to dynamically set privacy policies) 92(ability for user to set privacy preferences for objects-data and presentation in an understandable manner)96 (ability for user to set privacy preferences wrt re-cipients) 924 (ability to dynamically set policies withimmediate effect)

not fulfilledconflicts withcomments Requires additional work a See 611b

D12-615

Requires additional work a Specification that datacontrollers must specify the purposes of the processingprior to initiating the processing

not fulfilledconflicts withcomments

This requirement will be fulfilled by WPs WP6 (615a)

Version 20

Source Re-quirement

D12-616

D12-77

not fulfilledconflicts withcomments Requires additional work by technical partners a

Specification of mechanism to determine compatibilityof purposes b Specification of mechanism enablingconsent capture for new or changed use (user call-back) except where processing is legitimate pursuantto another basis (see 610)

This requirement will be fulfilled by WPs WP3 7 (616a) WP2 (616b)Source Re-quirement

D12-617

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of obliga-

tion for TAS3 participants to have a privacy policy thatarticulates restrictions and obligations with regards tosubsequent use of personal data it has under its con-trol

D12-618D12-6181D12-61823

215 (accountability) 41 (enforcement of privacy pref-erences within TAS3)

shall be ensured that when personal data is transmittedto a non-TAS3 participants or is exported from the net-work the recipient shall be informed of the restrictionsand obligations of use (for 618) b Specification of hownon-TAS3 participant shall be legally bound to respectsuch restrictions and obligations (for 6182) c Speci-fication of how it shall be ensured that data subject isaware that data recipient is not a TAS3 participant (for6183)

This requirement will be fulfilled by WPs WP 2 7 (618a) (within the network) WP6 (618b)WP6 9 (618c)

Source Re-quirement

D12-619

41 (enforcement of privacy preferences)

Version 20

comments Requires additional work a Specification of how com-patibility with specified purposes shall be technicallyenforced b See also 616a

D12-620

is fulfilled by D12-95is partially fulfilledbynot fulfilledconflicts withcomments

D12-621D12-622

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of how it

shall be ensured that processed personal data is notexcessive in relation to the specified purpose

D12-623

is fulfilled by 311 (privacy preferences granular access control andbusiness process) 220 (only authorized disclosuresand actions) 76 (authorization required for any action)921 (different levels of authorization) 923 (granularaccess by processes)

D12-624

75 (only provide minimum of credentials needed) 912(user identification only possible after appropriate au-thentication and authorization) 78 (prevent collusionto determine identity user without consent) 716 (userchoice of pseudonyms)

not fulfilledconflicts withcomments Requires additional work a Specification of how un-

necessary leaking of identifiers shall be avoided

This requirement will be fulfilled by WPs WP2Source Re-quirement

D12-6241

75 (only provide minimum of credentials needed) 726(consent for use of personal data and credentials)

Version 20

not fulfilledconflicts withcomments Requires additional work a Specification of how user

will be able to choose among IdPs

D12-625D12-6251D12-6252D12-6253

in which data must be anonymyzed or deleted (for 625)b Specification of how storage duration shall be deter-mined (as part of the serviceprocess definition) andenforced (for 6251) c Specification of data life cy-cles and their management (for 6252) d Specificationof technical obligation languages which stipulate afterwhich time-span deletion is mandatory (for 6253)

This requirement will be fulfilled by WPs WP6 9 (625a) WP4 7 (625b) (for enforcement)NA (625c) WP2 (625d)

Source Re-quirement

D12-626D12-627D12-628D12-629

shall be determined which entities are authorized to actas data providers for which data sets (designation ofauthoritative sources) (for 626) b Specification of howtrustworthiness of information shall be ensured includ-ing review and update procedures (for 627) c Spec-ification of procedures on how to deal with suspectedinaccuracies (for 628) d Specification of procedureson how data subject will be able to verify accuracy ofdata prior to further processing (where appropriate) (for628)

This requirement will be fulfilled by WPs WP2 (discovery service) WP7 (for credentials)(626a) WP2 (rectification process) (626b) WP2(dashboard) 9 (626c) WP2 (dashboard) (626d)

Source Re-quirement

D12-630D12-6301

220 (only authorized actions) 919 (means to guaran-tee data integrity and authenticity)

not fulfilledconflicts withcomments Requires additional work a Specification on how mod-

ification rights shall be determined (need-to-modify)

Version 20

Source Re-quirement

D12-631

is fulfilled by 919 (means to guarantee data integrity and authentic-ity)

D12-6321

is fulfilled by (See also comments from architecture team)is partially fulfilledbynot fulfilled Xconflicts withcomments

This requirement will be fulfilled by WPs WP6 (632a) WP2 4 7 (632b)Source Re-quirement

D12-633D12-634

is fulfilled by 220 (only authorized disclosures and actions) 310(permissions only valid when needed) 920 (confiden-tiality during transmission) 76 (authorization requiredfor any action) 919 (means to guarantee data integrityand authenticity) 921 (different levels of authoriza-tion) 923 (granular access by processes)

D12-635

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of an orga-

nizational framework for information security manage-ment

This requirement will be fulfilled by WPs NA (635a)Source Re-quirement

D12-636D12-6361D12-6362D12-6363D12-6364D12-6365

is fulfilled by 218 (credible authentication) 73 (proof of identity)74 (presentation of multiple credentials) 75 (only pro-vide minimum of credentials needed) 79 (revocabilityof credentials) 712 (pull of additional user credentialsas required) 713 (ability to determine where additionalcredentials must be pulled from) 921 (different levelsof authentication)

is partially fulfilledbynot fulfilled

Version 20

conflicts withcomments

D12-637

is fulfilled by 220 (only authorized disclosures and actions) 311(privacy preferences granular access control and busi-ness process) 76 (authorization required for any ac-tion) 921 (different levels of authorization) 923 (gran-ular access by processes)

D12-6371

91 (secure access to data from a variety of sources)

not fulfilledconflicts withcomments Requires additional work a Specification of how a di-

rectory of resources shall be populated b Specificationof how categories of potential data recipients shall bedefined

This requirement will be fulfilled by WPs WP2 7 (6371a 6371b)Source Re-quirement

D12-6372

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of how per-

sonal data shall be categorized (type sensitivity)

This requirement will be fulfilled by WPs NASource Re-quirement

D12-6373

923 (processes may only access data needed to exe-cute successfully)

not fulfilledconflicts withcomments Requires additional work a Specification of how privi-

leges of (all) entities shall be determined

D12-6374D12-6376

729 (mapping of external attributes to authorization at-tributes)

Version 20

not fulfilled Xconflicts withcomments a Specification of how a list of valid recipients for each

object that qualifies as personal data shall be definableupon request b Specification of how authorization pro-files shall be defined (indicating which resource is ac-cessible to which type of entity in which capacity timeetc)

This requirement will be fulfilled by WPs WP 7 (6374a 6374b)Source Re-quirement

D12-6375

46 (override of ordinarily denied access)

not fulfilledconflicts withcomments Requires additional work a Specification of how ac-

ceptable purposes for access to any given data typeshall be definable upon request

D12-6375

This requirement will be fulfilled by WPs WP4 7 (6375a)Source Re-quirement

D12-6377

103 (detect failures in granting or denying access toresources with respect to policies)

not fulfilledconflicts withcomments Requires additional work a Specification of instances

which qualify as a security breach b Specification ofinstances in which security breach notification shall berequired c Specification of which entities must be no-tified in case of a security breach d Specification offollow-up of security breaches by notified entities

This requirement will be fulfilled by WPs WP2 10 (6377a) WP2 (abstract) (637b) WP2 ALL(6377c 6377d)

Source Re-quirement

D12-638

is fulfilled by 919 (means to guarantee data integrity and authentic-ity) 920 (confidentiality during data transmission)

Version 20

D12-639

78 (prevent collusion to determine identity user with-out consent) 716 (user choice of pseudonyms) 718(avoid linkage of sequential requests)

This requirement will be fulfilled by WPs WP2 3 4Source Re-quirement

D12-640

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of in stances

in which physical access control is appropriate b Spec-ification of how physical access control shall be realized

D12-641

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of obligation

for TAS3 actors to adopt internal privacy policies doc-umenting security measures b Specification of tech-nical measures which must be adopted within internalprivacy policies c See also 62e

D12-642

for TAS3 actors to institute confidentiality agreementswhere required by law or appropriate

D12-643

Version 20

comments Requires additional work a Specification of obligationfor relevant TAS3 actors to determine for each dataprocessing operation the controller what data shallbe collected and how for what purpose how it will beused who it might be shared with and how it will bemanaged

D12-644D12-6441D12-6442D12-6443D12-645D12-6451D12-6452D12-6453D12-646D12-6461D12-6462D12-6463D12-647D12-6471D12-6472D12-648D12-6481D12-6482D12-649D12-6491D12-650

211 (functionality of TAS3 must be transparent) 43(capability to demonstrate security and trust featuresof TAS3 to users) 925 (prior information concerningimplications privacy preferences) for 644

not fulfilledconflicts withcomments Requires additional work a Specification of obliga-

tion for relevant TAS3 actors to notify the data subjectof -identity of the controller -purposes of processing-(categories of) recipients -obligatory or voluntary na-ture of reply (where appropriate) and consequencesof failure to reply -right of access and rectification -inthe event of indirect collection categories of data con-cernedb Specification on how this information shall be com-municated to the data subject

This requirement will be fulfilled by WPs WP6 (645a) WP6 WP9 (645b)Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

77 (ability to dynamically set privacy policies) 86(ability to store and modify personal data) 92 (abilityfor user to set privacy preferences for objectsdata andpresentation in an understandable manner) 96 (abil-ity for user to set privacy preferences wrt recipients)924 (ability to dynamically set policies with immedi-ate effect) for 652 (blocking and modification) 728(summary audit trails) 98 (ability for data subject tosee which entity has requested access and whethergranted or denied) for 653 and 660 (past recipients)

not fulfilledconflicts withcomments Requires additional work a Specification of obligation

for relevant TAS3 actors to accommodate data subjectrequests to access amend block or erase personaldata b Specification of how such requests shall be ac-commodated and which criteria shall be applied (egwhen should request for modification be granted au-tomatically when is additional assurance necessarywhen does an overriding interest exist etc) c Speci-fication of how data subject shall be informed of how torequest access amendment blocking or erasure

Version 20

This requirement will be fulfilled by WPs WP6 (651a) WP2 (dashboard) WP7 (authorization)WP9 (pilots) (6511b 651c)

Source Re-quirement

D12-658

for relevant TAS3 actors to communicate modificationsor blocking pursuant to data subject request to thirdparties to whom data have been disclosed b Speci-fication of how such notice shall be communicated tothird party recipients

This requirement will be fulfilled by WPs WP6 (658a) WP2 7 (658b)Source Re-quirement

D12-663D12-664D12-6641D12-6642D12-6643

is fulfilled by 95 (audit trail of who accessed personal data whenand for what purpose) 918 (journaling of data) for663 44 (proof of processing in compliance with poli-cies) for 6641-2-3

D12-665

217 724 (untamperable audit trail)

not fulfilledconflicts withcomments Requires additional work a Specification of how com-

pleteness of the audit trail shall be ensured

This requirement will be fulfilled by WPs WPs 2 7 8 9 10 (665a)Source Re-quirement

D12-666

211 (functionality of TAS3 must be transparent)

not fulfilledconflicts withcomments Requires additional work a See 643a 645a 645b

D12-667D12-6681D12-6682

Version 20

comments Requires additional work a Specification of how loginformation shall be stored in particular which format(pseudonymized yn) it shall be processed b Specifi-cation of how separation of duties (and correspondingprivileges) shall be organized

This requirement will be fulfilled by WPs WP 2 9 (667a) WP2 ALL (667b)Source Re-quirement

D12-668

is fulfilled by 724 (confidentiality of audit trail)

D12-669

is fulfilled by D12-101 D12-102 D12-109 D12-1010

D12-671

for TAS3 participants to co-operate with entities in theTAS3 network charged with oversight and audit

D12-673D12-6731D12-6732

D12-215 D12- 44

not fulfilledconflicts withcomments Requires additional work a Specification of how non-

repudiation shall be ensured b See also 66cThis requirement will be fulfilled by WPs WPs 2 7 (673a)Source Re-quirement

D12-674

Version 20

comments Requires additional work a Specification of instancesin which automated notification shall be instituted bSpecification of how such notifications should be fol-lowed up c See also 6377a-d

This requirement will be fulfilled by WPs WP2 7 ALLSource Re-quirement

D12-675

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of proce-

dures which enable identification of the source of per-sonal data upon request as well as the purpose forprocessing

D12-676

tion to ensure that data recipients outside the TAS3 arebound to adhere to the usage directives and policiesarticulated by the TAS3 network

D12-677D12-6771D12-6772D12-678

215 (accountability) 54 (trust feedback mechanism)

not fulfilledconflicts withcomments Requires additional work a Definition of complaint

capture system and follow-up procedures (in additionto reduction of trust score) including processes for pro-viding redress

D12-679

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Ensure that TAS3 par-

ticipants provide evidence of notification of their DPAduring intake process

Version 20

61 Interaction Analysis of New Legal Requirements

After the analysis of the interaction between the legal and technical requirements WP6 and the other WPsnoticed the need for further legal requirements The complete list of new edited and deleted requirements arecaptured in Appendix B The final list of legal requirements are listed in Deliverable 61 The interactions of thenew requirements are documented in the following template

Source Re-quirement

D12-680

D12-727

not fulfilledconflicts withcomments Requires additional work a Further specification of

actors roles and responsibilities b See also Req 69This requirement will be fulfilled by WPs WP2 ALL (680a)Source Re-quirement

D12-681

is fulfilled by 99 (ability for users to modify privacy preferences)924 (act on dynamically set privacy policies with im-mediate effect)

D12-682

D12-34 (consistent identification throughout the exe-cution of a business process instance)

ambiguous identification shall be ensured across ser-vice providers (beyond business process instances)

D12-683

in which delegation might be restricted b Specifica-tion of how it shall be ensured that delegation will onlyexecuted where permitted by the appropriate policy

Version 20

D12-684

is fulfilled by D12-73

D12-685

D12-6851

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of which en-

tities should be notified in case the glass is broken bSpecification of how notification of these entities shallbe ensured c Specification of follow-up procedures

This requirement will be fulfilled by WPs WP2 7 ALL (6851a) WP7 (6851b) WP2 7 ALL(6851c)

Source Re-quirement

D12-686

D12-916

in which (temporary or permanent) duplication shall bedeemed necessary

D12-67D12-6871

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of how user

will be able to set privacy preferences with regards touse of feedback information b Specification of how op-erator of Trust Reputation Server shall be bound to onlyprocess feedback information in accordance with thepolicy expressed by the user c See also 511

Version 20

D12-688D12-6881D12-6882

in which outsourcing or delegation is restricted b Spec-ification of how it shall be ensured that TAS3 partici-pants are contractually bound to only select processorswhich offer sufficient guarantees in terms of organiza-tional and technical measures c Specification of how itshall be ensured that TAS3 participants are contractu-ally bound to conclude a contract with their processorscontaining the elements required by art 17 of Directive9546EC

This requirement will be fulfilled by WPs WP6 (688a 688b 688c)

62 Mapping of Legal Requirements to Architecture

In the mapping of the legal requirements to architecture we first asked the WP6 to identify requirements thatspecifically interact with WP2 These interactions were than commented by the WP2 architecture team Thearchitecture team indicated whether the legal requirement could be addressed in the architecture and if sowhether it already had been addressed or there was a gap

Source Re-quirement

D12-69D12-670D12-672

Comments of WP2 This requirement may only be fulfilled in a concrete im-plementation of TAS3 in a given context This can bedone for the demonstrators but will have to remain openfor future contexts or will be specific to an implementa-tion of TAS3

Source Re-quirement

D12-616

D12-77

Version 20

comments Requires additional work by technical partners aSpecification of mechanism to determine compatibilityof purposes b Specification of mechanism enablingconsent capture for new or changed use (user call-back) except where processing is legitimate pursuantto another basis (see 610)

Comments of WP2 This matter is addressed in D12-24 Section 274User Interaction

Source Re-quirement

D12-618D12-6181D12-61823

shall be ensured that when personal data is transmittedto a non- TAS3 participants or is exported from the net-work the recipient shall be informed of the restrictionsand obligations of use (for 618) b Specification of hownon- TAS3 participant shall be legally bound to respectsuch restrictions and obligations (for 6182) c Speci-fication of how it shall be ensured that data subject isaware that data recipient is not a TAS3 participant (for6183)

Comments of WP2 This is currently not addressed in the architecture ofTAS3

Source Re-quirement

D12-624

Comments of WP2 this requirements is addressed in D21 Section 321Attribute Pool Model

Source Re-quirement

D12-625D12-6251D12-6252D12-6253

Version 20

comments Requires additional work a Specification of instancesin which data must be anonymyzed or deleted (for 625)b Specification of how storage duration shall be deter-mined (as part of the serviceprocess definition) andenforced (for 6251) c Specification of data life cy-cles and their management (for 6252) d Specificationof technical obligation languages which stipulate afterwhich time-span deletion is mandatory (for 6253)

Comments of WP2 addressed in D24 Section 210 Simple ObligationsLanguage (further languages can be extended to spec-ify this but currently it is only SOL that we have madesure addresses this specification)

Source Re-quirement

D12-626D12-627D12-628D12-629

Comments of WP2 This requirement still needs to be refined to be ad-dressed by the architecture It is possible that this re-quirement may only be fulfilled in a concrete implemen-tation of TAS3 in a given contextThe dashboard willalso partially address this requirement

Source Re-quirement

D12-6321

is fulfilled by D12-919 D12-920is partially fulfilledbynot fulfilledconflicts withcomments

Comments of WP2 this requirements is addressed in D24 Section 222Liberty and ID-WSF Profile D21 Section 38 Proper-ties of Web Service Binding It is also addressed in theabove mentioned requirements from WP9

Source Re-quirement

D12-6371

Version 20

comments Requires additional work a Specification of how a di-rectory of resources shall be populated b Specificationof how categories of potential data recipients shall bedefined

Comments of WP2 This requirement may only be fulfilled in a concrete im-plementation of TAS3 in a given context

Source Re-quirement

D12-6377

Comments of WP2 This requirement is addressed in the annexes onThreat analysis and Risk assessment in D21

Source Re-quirement

D12-639

Comments of WP2 This requirement is addressed in D41 Section 11 For-mat and Properties of Identifiers which is also imple-mented by the architecture team

Source Re-quirement

D12-641

Comments of WP2 This requirement is addressed in D21 Annex Com-pliance Requirements and in the Annex CR251-OpsManual of the same deliverable

Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

is fulfilled by

Version 20

Comments of WP2 This requirement is addressed in D24 Section 27 Re-alization of the Audit and Dashboard Function

Source Re-quirement

D12-658

Comments of WP2 This is discussed but not properly addressed in D21Section 62 Right of Access Rectification and Deletion

Source Re-quirement

D12-665

Version 20

Comments of WP2 This problem has two parts 1)you do not delete whatis there (this is addressed in D21 Section 61 Dash-board and D24 Section 27 Realization of the Audit andDashboard Function 2) more difficult to guarantee thatthings are logged in the first place and this requireshuman audit Human audit comes in two categories i)the end-user self-audit which is facilitated through theDashboard and ii) Audit Analysis which is done by ex-ternal auditing organizations this is mentioned in D21Section 21 There is also a D21 Section 65 FormalCompliance Audits

Source Re-quirement

D12-667D12-6681D12-6682

is fulfilled byis partially fulfilledbynot fulfilled Xconflicts withcomments Requires additional work a Specification of how log

information shall be stored in particular which format(pseudonymized yn) it shall be processed b Specifi-cation of how separation of duties (and correspondingprivileges) shall be organized

Comments of WP2 667a requirement is addressed in D21 Annex Enu-meration of Audit Events (although this does not go intodetail) WP2 finds it more appropriate that 667b is ad-dressed by WP7

Source Re-quirement

D12-673D12-6731D12-6732

D12-215 D12- 44

repudiation shall be ensured b See also 66cComments of WP2 This is a gap which will be addressed by WP2Source Re-quirement

D12-674

in which automated notification shall be instituted bSpecification of how such notifications should be fol-lowed up c See also 6377a-d

Comments of WP2 WP2 addresses this requirement in D21 Section 62Right of Access Rectification and Deletion

Source Re-quirement

D12-675

is fulfilled byis partially fulfilledbynot fulfilled X

Version 20

conflicts withcomments Requires additional work a Specification of proce-

Comments of WP2 WP2 D24 Section 2102 Matching Pledges to StickyPolicies and Obligations addresses that what the poli-cies are conveyed D21 Section 243 Using StickyPolicies to Protect Data potentially this is also ad-dressed in D21 Section 41 Protocol Support for Con-veyance of Sticky Policies also in D24 Section 211Realization of Sticky Policies These address the poli-cies but the data aspect is addressed in D21 Section621 Identification of Originating Authority (675a)

Source Re-quirement

D12-680

D12-727

actors roles and responsibilities b See also Req 69Comments of WP2 WP2 addresses this requirment in D24 Section 12

Composition and Co-location of Architectural Compo-nents this section discusses the types of conflicts ofinterest eg why you should not be an SP and IdP atthe same time

Source Re-quirement

D12-682

Comments of WP2 WP2 addresses this requirement in D41 in Section 11(682a)

Source Re-quirement

D12-6851

Version 20

Comments of WP2 WP2 states that this is a businesslegal definition andnot a technical one

Source Re-quirement

D12-686

D12-916

Comments of WP2 WP2 addresses this requirement in D21 Section 321Attribute Pull Model which also includes a plan to avoidduplication

Source Re-quirement

D12-67D12-6871

Comments of WP2 WP2 thinks that WP5 should state their fulfillment ofthis requirement

Version 20

7 Mapping Global Requirements to the TAS3 Ar-chitecture

Requirements elaboration in D12 is based on viewpoints elicitation and analysis There is always a dangerthat when the focus is on the viewpoints that global requirements are not properly addressed In order to ad-dress this problem we have asked the architecture team to identify global requirements during the requirementselaboration activities Later the requirements team was asked to map these requirements to the different archi-tecture components developed by the TAS3 WPs The results of this mapping as well as the accompanying gapanalysis is listed below using a mapping template

ReqID D12-21Requirement TAS3 Architecture MUST be feasible to implementEvaluation The reference implementation in form of ZXID is a feasibility proof

given that it was implementable within the architecture is a feasibilityproof Further several of the components have been implemented ina reasonable amount of time and guarantee good performance

To doReqID D12-22Requirement TAS3 Architecture MUST be feasible to deployEvaluation The IDP implemented (that will be implemented) at demotas3eu

shows that it is feasible to deploy TAS3 By month 27 we will be ableto say that it is fully deployable The demos prepared by CustodixRisaris and Nottingham will also be used to validate the deployabilityThis is work in progress although early experiences show that it isfeasible to deploy TAS3

To do The demonstrators are still to be completed and evaluated with re-spect to the validation of the fulfillment of this requirement

ReqID D12-23Requirement TAS3 Architecture MUST support plurality of service business mod-

elsEvaluation TAS3 contains a discovery service This is implemented in the com-

ponent T3-IDP-Map There is a ZXID implementation of the discoveryservice Plurality of service business models cannot only be guaran-teed technically It also depends on the business model of TAS3

which is still to be completed In the combination of the technologyand the business model will this requirement be fulfilled

To do The business model has to be completed This needs to be in amanner with enables plurality of business models

ReqID D12-24Requirement TAS3 Architecture MUST support multiple software suppliers

Version 20

Evaluation TAS3 is currently compliant with existing standards Therefore it isconducive to enabling a multi-vendor market This is also validatedin the different components which are developed using different iden-tity management standards in the components T3-IDP-ZXID and T3-IDP-SHIB In that sense we have a multi-vendor experience In thecase of the PDP authorization component we also have multi-vendorexperience The PERMIS PDP SUN PDP and Trust PDP simulatea multi-vendor situation There is also a dummy PDP which wasSamporsquos own authorization clientThere are though problems with the multi-vendor requirementsTAS3 in its current form TAS3 is very much ZXID dependent There isa possibility that Custodix software is not This needs to be checkedCurrently we also do not have a second implementation of the stackIn deliverable 24 there is a TAS3 (official) API section Once com-pleted we will have an out-of-the-box specification of the TAS3 APIfor several programming languages

To do Find out if Custodix is also ZXID dependent or if they are using dif-ferent standards Confirm that the API is the multiple programminglanguage solution that it claims to be

ReqID D12-25Requirement TAS3 Architecture MUST be platform independentEvaluation ZXID has been imported to both linux and windows So currently it

is a multi-platform architectureTo doReqID D12-26Requirement TAS3 Architecture MUST be programming language agnosticEvaluation 26 We have implementations in PHP and java These can be found

in the following components T3-SSO-ZXID-JAVA T3-SSO-ZXID-MODAUTHSAML T3-SSO-ZXID-PHP The reference implementationsupports JAVA PHP C and C++ The last two were not part of theTAS3 requirements but were desirable by Sampo Hence the archi-tecture is programmable using multiple programming languages Itis not a JAVA only architecture In Deliverable 24 there is a TAS3

(official) API section out-of-the-box TAS3 will specify for several pro-gramming languages the API

To do Check end-results of Deliverable 24 definition of APIReqID D12-27Requirement TAS3 Architecture MUST be fail safe ie failure should not lead to

security breachEvaluation This requirement is currently not demonstratedfulfilledTo do Fail-safe design implementation and related security checks have

to be systematically done in many parts of the architecture CanWP10CNR do compliance checking for a fail-safe architecture Oris WP10CNR just a test frame Then how is this systematic checkgoing to be completed

ReqID D12-28Requirement TAS3 Architecture MUST be availableEvaluation A lot of the services in the architecture can be backed up An al-

ternative IDP can easily be found The storage persistent parts onthe other hand are not easy to replace if they fail on availability InDeliverable 24 Section 5 starts addressing availability issues It iscalled resilient deployment architecture Currently this section doesnot contain much detail Even the TAS3 wiki has a number of sin-gle points of failure Possibly it is not in the scope of this project todemonstrate the fulfillment of this requirement

To do Decide if this requirement is within the scope of TAS3 project

Version 20

ReqID D12-29Requirement Implementation MUST correctly implement TAS3 ArchitectureEvaluation The integration testing demonstrates interoperability between ven-

dors But this is a weak demonstration of correctness but it is betterthan nothing But how do you demonstrate correctness A toughthing to do is to provide software proofs You can also do some cor-rectness checks at the interface level or using unit testing and somecompliance testing The complexity of a constellation like TAS3 maybe such that you cannot test it exhaustively Even testing a compo-nent like the PDP is complex

To do This is a currently unaddressed requirement which demands addi-tional communication and planning If WP10CNR is not doing thissort of testing needs to be clarified

ReqID D12-210Requirement TAS3 MUST appear to the users to work correctlyEvaluation This is a quality requirement Ideally this is part of what UNIZAR

should be testing But it is likely that UNIZAR will only look at theinterface and say if it is friendly or not This requirement is not ad-dressable in the architecture Some end-to-end testing is also con-ceivable The end-users of the demonstrators can be part of suchtesting and may also state the functionalities that they do not under-stand This will require cooperation between WP9 and WP12With respect to the specification if we specify some (work) flowsthe flows have to be within reasonable expectation of what the usersthink will happen But where do we specify flows Who will dothe specification of what the user experience looks like Maybe thisshould be part of the pilots These matters to not get addressed orspecified in the architecture although they probably should This isa gap in the project We state that user interaction and experienceis important but nobody is addressing this The dashboard interfaceprototype Lex showed in Budapest could be one of the matters ad-dressed to fulfill this requirement Is the dashboard a part of anyspecific WPIs it going to be part of WP9

To do This requirement is currently not addressed Possible candidatesare UNIZAR WP9 or others addressing the user experience andcorrectness of functionality The work on the Dashboard interfacecan be seen as fulfilling this requirement partially Responsibilitiesfor this requirement have to be distributed

ReqID D12-211Requirement The functionality of TAS3 must be transparent to the users (user can

see what is going on)

Version 20

Evaluation A large part of this requirement is fulfilled with the development ofthe dashboard This requirement is an overall guiding principle forthe user interface We need to define how the dashboard is going tomake the system transparent to the user Koblenz is developing partof the dashboard including an audit trail search tool The module iscalled T3-LOG-GUI And part of the functionalities in the compo-nent T3-DASH fulfill this requirementThe business process modeling could also be used to provide moretransparency If the users are aware of the business processes thenthey can then understand how it is supposed to work and under-stand if there are anomalies in the system If it is explained andunderstood this is the process then the user can inform herself andmake a well informed decision which means the business processeshave to be modelled properly in an understandable manner Sampothinks T3-BP-GUI is responsible for thisLetrsquos take for example the TAS3 service selection The user has aprocessing need and once the candidates for the service have beenfiltered for suitability by using the trust engines and other criteria andmore than one candidate remains the user needs to make a choice(informed) Essentially TAS3 should guarantee that the ones rankinglow on the trust model are eliminated But there is a point where themachine should not make a decision In some cases it may be ap-propriate to have a policy driven selection but human interaction se-lection may often be desirable This is the service selection dilemmaHow does that selection happens and how it is user centric and con-trolled by the user is part of comprehensibility and transparency tooFrom the legal side it is probably also very important that the usercan make an informed decision and can judge appropriately whatthe system is doing

To do Is the componentWP T3-BP-GUI addressing the problem of makingthe systembusiness process transparent to the user Is it neces-sary legally to make anything transparent to the user What is thesufficient standard of transparency and comprehensibility from a le-gal perspective Are there different requirements for different appli-cation domains

ReqID D12-212Requirement TAS3 MUST be comprehensible to the user The user MUST be able

to understand what has happened what should have happened andwhat will happen

Evaluation see D12-211To doReqID D12-213Requirement TAS3 MUST be easy to use

Version 20

Evaluation This requirement should be split into three with respect to the dif-ferent rdquouserrdquo groups for users deployersclients and for develop-ers TAS3 ease-of-use for users The ease-of-use for the users isa matter of the GUI packages which are dealt with in the followingcomponents T3-BP-GUI T3-LOG-GUI T3-POL-GUITAS3 ease-of-use for deploying clients This is the case as a result ofa lot of the automatic configuration features eg the SAML 20 wellknown location method of meta-data exchange For two entities inthe TAS33 infrastructure to communicate they need to know wherethe certificates end-points and other configuration parameters arelocated In D24 this kind of exchange is prescribed We assume thatif there are readily available products then it will be easy to deployTAS3 Last the architecture documentation is comprehensible andmakes it easy to understand and deploy TAS3 (this is to be validated)TAS3 ease-of-use for programmers TAS3 provides a reference im-plementation T3-IDP-ZXID T3-SSO-ZXID The programmers arealso provided with a standardized API

To do We need validation of the ease-of-use concepts listed above includ-ing ease of use of documentation the ease-of-use of GUIs and theIDP and SSO implementations

ReqID D12-214Requirement TAS3 MUST appear to the user to be privacy protectiveEvaluation The privacy protection has to provide the user with control while not

being intrusive eg the user has to be asked for consent when thisis necessary but there should be also some automation available ifthe user prefers to automate some of the decisions or consent is notnecessary Matters of a similar kind are addressed in different partsof the architectureMechanisms for minimal disclosure There are ways to negotiatewhat you reveal in our system This is especially addressed whendoing trust and privacy negotiationMechanisms for control and data protection The authorization com-ponent like the sticky policies play an important role in providingusers with control The relevant components are T3-POL-GUIT3-POL-NLP T3-POL-WIZ T3-PEP-AI provides the enforcement ofsticky policies and obligationsMechanisms for developing privacy practice The trust componentshelp the users in developing practices with respect to their privacywith trusted parties T3-TRU-FB T3-TRU-RTMIt is currently unclear if we need a separate service for conveying thetrust or if it can be conveyed through the audit bus Users throughtheir ranking and feedback trigger trust and reputation related eventsIf these events go through the bus some of these interesting eventslike audit trail items could be considered as events part of the trustformation Communicating trust feedback over the bus means theuser has to send the feedback once If not then the user has to sendthe feedback a second time to a separate service This means thatthe user has to bother to send a message to the service provider Incomparison an audit trail is necessary and mandatory Legally anaudit trail is expected At the same time most of the trust feedbackis in the audit trail So there is an existing economy from which todevelop the trust management service in any case both audit busand the dashboard are important components of privacy as practiceT3-DASH T3-BUS-AUD

Version 20

To do What else can we say about the trust and privacy negotiation com-ponent Clarify if a separate trust service provider is necessary andifhow it can be integrated with the audit information that flows overthe bus

ReqID D12-215Requirement TAS3 MUST make it possible to hold people and companies account-

able for the activities with respect to personal dataEvaluation The audit trail is the main tool with which we achieve oversight and

accountability There is a requirement for everybody to keep au-dit trail The TAS3 audit trail is spread throughout the architectureIt touches every component of the architecture that needs to beaudited The audit trail also has a number of facilitating compo-nents T3-LOG-SAWS T3-LOG-WRAP-SAWS T3-LOG-WRAP-ZXIDT3-LOG-ZXID T3-DASHAnother aspect of accountability is temper proof and non-repudiation These properties can be addressed in the stack Thestack is addressed in the component T3-STACK But a lot of thefunctionality of the TAS3-stack is integrated into a number of ZXIDmodules Therefore temper resistance and non-repudiation alsoneeds to be addressed in this component T3-SSO-ZXID In generalboth properties are addressed in the design and implementation

To do It needs to be validated in the future if temper-resistance and non-repudiation have been addressed in T3-Stack and T3-SSO-ZXID

ReqID D12-216Requirement TAS3 MUST mitigate risks or prevent risks to the trust and security

of the architectureEvaluation The current threat modelrisk model part of the architecture has not

been completed (Task 28) There are some components that mitigatesome of the risks that would be discovered in the threat and riskanalysis model The operation monitoring component has intrusiondetection protection against viruses and buffer overflows Generalnetwork security would apply but is not part of the research projectNevertheless you cannot address this requirement without havingdone such an analysis

To Do The threat and risk analysis is to be completed in Task 28 Respon-sible are Sampo and SAP Completion in month 27

ReqID D12-217Requirement TAS3 MUST provide an untamperable audit trailEvaluation 217

The temper-resistant audit trail is taken care of in T3-LOG-SAWSwithin the secure auditing web services T3-LOG-ZXID which in prin-ciple aim to address the same matter in a parallel implementationThe issue is also addressed in T3-DASH The bulk of untemperabilityis done by SAWS SAWS has a vulnerability that an attacker cannotmodify but might be able to find a way to omit or delete audit trails Atcertain check points audits will become undeletable but in betweenattacks are possible Sampo is not convinced about the absoluteundeletability of the audits with SAWS Hence Sampo proposes aback to the dash to protect against the types of deletion attacks thatSAWS and ZXID cannot fully mitigate

To Do T3-DASH has to implemented in such a way to mitigate the temper-ingdeletion risks not addressed by SAWS

ReqID D12-218Requirement Authentication in TAS3 MUST be credible

Version 20

Evaluation Authentication of the end-users The following components addressthe credibility of authentication for the end-users T3-IDP-ZXID sup-ports both client ceritificates (e-id) and the hardware tokens suchas yubikey T3-IDP-SHIB they also support something better thanpassword Authenticating the end-user is convincingly implementedby the hardware tokens One could easily also implement RSA andother authentication tokensAuthentication of system entities By system entities we mean enti-ties such as the idp and service providers etc Their authenticationis done by the use of client certificates issued to a server at TLS andusing digital signatures Both of these mechanisms are checked andvalidated using the following components T3-STACK creates andchecks TLS and digital signatures T3-ACBS provides an authoriza-tion credential validation service

To Do Check what kind of authentication Shibboleth provides to completethe evaluation of the authentication requirement for users

ReqID D12-219Requirement Authorization in TAS3 MUST be credibleEvaluation 219

This may currently be a weak spot in the architecture It may provedifficult to develop rule sets that are correct Nevertheless the prob-lem is addressed in all components starting with T3-PDP- pack-ages And in the T3-PEP- In general the following two rules haveto be satisfied 1) the right authorization decisions are being made2) and the decisions are enforced We are developing mechanisms toput both in place

To Do When and how do we evaluate the liminations of the PEP and PDPcomponents

ReqID D12-220Requirement TAS3 MUST guarantee only authorized disclosures and actionsEvaluation This is the enforcement part of requirement 219 It is addressed

in T3-PEP- This requirement is also related to the obligations man-agement University of Kent has an obligations manager but wecurrently do not have a module in our component list addressing thisproblem The likely candidate where this is happening is T3-PEP-AI

To Do Check and confirm that either T3-PEP-AI is addressing this require-ment or delegate to another component the fulfillment of this autho-rization requirement

ReqID D12-221Requirement TAS3 MUST implement data protection legislation in technologyEvaluationTo Do 221 The evaluation of this requirement will be completed with Bren-

dan and JoeReqID D12-222Requirement TAS3 MUST permit access to the audits for legitimate authorities if

this is legally necessaryEvaluation The access to the audit is generally made possible with T3-LOG-

SP This component exposes the audit trail to authorized parties de-pending on what legitimate authorization is defined as But guaran-teeing that only those with legitimate authority use this functionality isnot only a matter of technology but also needs to be defined thoughorganizational policies It would be nice to have a library of defaultpolicies that address such law enforcement measures

Version 20

To Do A discussion is necessary as to if a new component named T3-DEFAULT POLICY should be added in which a library of reusablepolicies that address data protection issues and legitimate accesspolicies are collected Brendan and Joe should be consulted withrespect to the feasibility and desirability of such a component

ReqID D12-223Requirement Semantic interoperability should be achieved across web services

and business processesEvaluation We achieve semantic interoperability by trying to avoid divergent se-

mantic vocabularies D24 specifies the appropriate trust levels thatcan be used Ontology activities to improve the semantics and hencethe use of a common vocabulary between the partners will be ad-dressed in the following components T3-ONT-LCO T3-ONT-SO T3-ONT-UCO This ontology task is at a very high level There is nosingle other component that is integrating machine readable ontol-ogy into their system There is no commitment from quentin that theLCO and UCO are machine readable They are also not actionableCurrent implementers see great utility in mapping or translating cre-dentials and attributes and this is realized by Credential ValidationService (T3-ACVS) However this module is currently using simplemapping table approach and does not really integrate to the ontologycomponents (T3-ONT-)

To Do The integration of the ontology components with the semantic needsof the rest of the components should be addressed

Version 20

8 Mapping WP Requirements to the TAS3 Archi-tecture

The following is a mapping of the requirements to the TAS3 architecture The mapping is not yet completeSome of the requirements for WP5 WP7 WP8 WP9 are missing unless they were redundant requirementsThe mapping of the requirements of WP10 are missing completely Further our legal experts have startedcommenting on all the requirements individually and the mapping of the requirements to the architecture Bothof these activities are underway and will be completed in the next iteration of D12 Here we present the latestversion of the requirements mapping to the architecture

The mapping of the requirements to the architecture also documents redundant requirements requirementsthat are out of the scope of the architecture and any conflicts between requirements from the perspective of thearchitecture team

Req Primary Re-sponsibility

Architecture Com-ponent

Explanation of how component fulfills require-ment

D12-21-FeasImp

WP2 WP12 General Only a correct architecture is feasible Correctnessis to be ensured by editorial excellence and review

Sufficient architecture documentation is a secondenabler of feasibility WP2 will work in close interac-tion with WP8 and WP9 to ensure knowledge trans-fer

Availability of ready made solutions especiallyopen source solutions for the components of thearchitecture that are not in research scope is fun-damental for implementation feasiblity Architecturehas been designed to be standards aware and op-erational with existing software libraries

D12-22-FeasDep

WP2 WP12WP8

General All ldquohowsrdquo of D12-21-FeasImp apply Further thearchitecture and software documentation must ad-dress how to configure the modules correctly

Deployment feasibility also means that algorithmsthat are used either through architecture choice orimplementation choice must be efficient enough torun in a production environment Of particular con-cern are the number of public key operations re-quired (eg digital signature generation and veri-fication as well as TLS connection establishment)and the number of authorization decisions that needto be made The general approach has been toemphasize correct no short cuts implementationof functionality with minimum number of expensiveoperations However in no case has functionalitybeen traded for efficiency Such trade-off may even-tually be made in a future release of the architecturebased on pilot experience (WP9)

Of particular importance from the feasibility per-spective is that the architecture does not require PKIto be deployed to the end users (however PKI forend users can be deployed in context of the TAS3

architecture)

Version 20

D12-23-BMs

WP2 WP7 D41 Discovery IDMapper RegistryServer

Service business models can range from hardwiredmonopoly environment to fully dynamic competitiveenvironment Generally the latter is more demand-ing So the architecture specifies the discovery fam-ily of functionality to support this The monopolycase is handled as a special case where only oneprovider can be discovered

D12-24-MultiVendor

WP2 TAS3

CAAnnex A Protocols Standards based architecture is inherently easier for

multiple vendors to implementAnother multivendor feature is the Royalty Free

licensing of included Project Background and theProject Foreground as foreseen in the TAS3 Con-sortium Agreement The CA also foresees use ofBSD style Open Source licenses in the project de-liverables further permitting commercial reuse ofproject deliverables

D12-25-Platform

WP2 Annex A Protocols Multiplatform support is mainly a matter of not us-ing solutions that are available on just one platformTAS3 architecture specifies standards a based ap-proach so multiplatform support requirement is welladdressed

D12-26-Lang

WP2 Annex A Protocols Most important way to support multiple program-ming languages is to specify all APIs and interac-tions on wire protocol terms rather than in program-ming language specific API terms All standards ref-erenced by the Architecture Protocols annex shallbe wired protocol standards rather than program-ming APIs

Another way to support multiple programming lan-guages is using libraries that provide multiple inter-faces eg by using SWIG [SWIG] to translate Cinterfaces to a number of scripting languages

D12-27-Safe

WP2 Annex F ThreatsNew section TBW

The Threats section specifies some Denial of Ser-vice attacks and strategies for surviving them

Architecture does not currently (May 2009) ad-dress Fail Safety adequately This will be addressedby a special analysis section that will be included inthe next architecture deliverable

See also Reqs D12-68-UAc and D12-97-UAc

D12-91-SecData

WP2 D21 sec 321 At-tribute Pull Model

TAS3 core security architecture flows and in par-ticular Attribute Pull model ensures secure accessThe discovery functionality further facilitates use ofmultiple sources

Version 20

D12-92-UPA

WP7 GAP Policy editing is supposed to solve this but currently(2010) we do not have satisfactory solution

The achievable granularity of control will greatlydepend on the abilities of the underlying data modeland Policy Enforcement Point (PEP) Especially incase of legacy systems it is unrealistic to expect fullygranular control

It may also be unrealistic to expect users to com-prehend the full detail of the fully granular data andpolicies

Finally determining and visualizing the full conse-quences of a policy choice is a difficult problemSee also D12-925-Consequences

D12-93-SSO

WP2 D24 sec 21 Sup-ported Authentica-tion and Login Sys-tems

The core security architecture flows include SingleSign-On

D12-95-Trail

WP2 D24 sec 27 Re-alization of the Au-dit and DashboardFunction

The Audit Bus collects summary of all the accessesThis summary will allow the user to use Drill In inter-face to access the detail of the audit trail

Access controls and authorization are applied interms of who can post to audit bus as well as whocan listen to the audit events Access controls alsodetermine whether drill down is available Accesscontrols ensure that only the user has access to hisdashboard

D12-96-UPADetail

WP7 GAP D24 sec211 System EntityAuthentication

Satisfying this requirement is a very tough policyediting job

Granularity down to organizational or server levelis easily achieved by the architecture and its Sys-tem Entity Authentication mechanims If granularityneeds to progress to level of individual users weencounter the issue of properly identifying the userwhen pseudonymous identifiers are used Gener-ally same solution as in delegation needs to beadopted use invitations to pseudonymously intro-duce the users to each other

D12-97-UAc

D12-98-UAudit

The Dashboard and audit drill down service providethis functionality subject to access controls

D12-99-UPADyn

WP7 WP2 D21 sec 41 Pro-tocol Support forConveyance ofSticky PoliciesD21 sec 623Propagation ofRectifications bythe OriginatingAuthority

The policy enforcement dynamically queries PolicyDecision Points This requrement is satisfied if theprivacy policies can be made dynamically availableto the PDP with immediate effect

A mechanism of such dynamic policy distributionis Sticky Policies Another is the Subscription andNotification PatternSee also D12-924-UPADyn

Version 20

D12-912-UID

WP2 D41 sec 11 For-mat and Propertiesof IDs

The pseudonymous properties of the identifiers en-sure that the identification of users is only possiblewith user consent (eg user says who he is) or byconsulting the detailed audit trail of the IdP or Dis-covery Service Such drill down is controlled by ap-propriate access controlsSee also Reqs D12-34-UID and D12-510-UID

D12-917-PolicyComb

WP7 D71 Sec 53 Con-flict Resolution Pol-icy D71 Sec 7 Dy-namic Managementof Policies Infras-tructure

The Master PDP will dispatch authorization requestto a number of PDPs depending on policy lan-guages employed as well as multiple policy authori-ties If multiple PDPs are consulted the Master PDPwill combine the results according to combinationpolicies

D12-918-Journal

WP2 D21 sec 61 Dash-board D21 An-nex NN Enumera-tion of Audit EventsD24 sec 27 Re-alization of the Au-dit and DashboardFunction

TAS3 addresses journaling in the audit sense inthat each operation is logged in summary form tothe audit bus However this does not log the ac-tual data to the Audit Bus This is to avoid Panopti-con threat centered around the Audit Bus and Dash-board seeing too much data and becoming fat tar-get Thus the journaling requirement may be in con-flict with req D12-224-NoPanoptThe TAS3 audit trail does not attempt to addressjournaling in the sense that database inconsistencycould be recovered

D12-919-Integ

WP2 WP4 D21 sec 38 Prop-erties of Web Ser-vice Binding D24sec 222 Liberty ID-WSF Profile D24sec 221 Frame-work D42 D81

The protocol bindings of the architecture apply dig-ital signatures and authentication at appropriateplaces to ensure this

The repository services ensure the integrity andauthenticity of of the data while in storage and whendelivered from storage

D12-920-Confid

WP2 D21 sec 38 Prop-erties of Web Ser-vice Binding D24sec 222 Liberty ID-WSF Profile D24sec 221 Frame-work

The protocol bindings of the architecture apply en-cryption and access control at appropriate places toensure this

D12-921-AnLvl

WP2 D24 sec 21 Sup-ported Authentica-tion and Login Sys-tems D24 sec 27Using Trust Scoringin Discovery

The authentication levels are expressed during SSOas Authentication Context Class Reference whichcan express the authentication technology as wellas the intitial strength of user intake registrationidentity proofing and vetting

The approach taken by TAS3 is compatible withmajor international standards and trends in eGov-ernment authentication and identity proofing

Authorization is performed based on authentica-tion and presented credentials Concept of ldquolevelrdquo isnot applicable to authorization

Levels of trust can be conveyed using the XACMLspecial status returns

Version 20

D12-922-TrustEst

WP6 WP5WP2

D62 sec 81 Intakeprocess D51 sec4 Trust ServicesD24 sec 212SAML item 11

A very basic level of trust is established at the part-ner intake phase

On technical level initial trust is established at themetadata exchange phase Afterwards the trust ismanaged using Trust and Reputation engine

D12-923-Min

WP3 WP7WP2

The business process modelling captures the dataneeds of a business process These needs are usu-ally satisfied by discovering an authority that cansupply the data and then querying this athority toobtain the data (pull model) Occasionally the pushmodel may be used aw well but it is difficult to orga-nize minimality of data access in push scenario

All data releases are subject to authorizationwhich is driven by policies The flexibility of policyformulation allows any scenario to be catered (butwrong policies can lead to inadvertent release ofdata)

D12-924-UPADyn

D12-925-Consequences

WP2 D21 sec 61 Dash-board

Ideally an identity mirror concept should be imple-mented Currently (2010) the best approximationthat allows the user to see where the data propa-gates is the DashboardSee also D12-92-UPA

Version 20

Requirementsfrom D12First it-erationthat havenot beenchanged D12-21 TAS3 Ar-chitectureMUST befeasible toimplement D12-22 TAS3 Ar-chitectureMUST befeasible todeploy D12-23 TAS3 Ar-chitectureMUST sup-port pluralityof servicebusinessmodels D12-24 TAS3 Ar-chitectureMUST sup-port multiplesoftwaresuppliers D12-25 TAS3 Ar-chitectureMUST beplatformindependent D12-26 TAS3

Architec-ture MUSTbe pro-gramminglanguageagnostic D12-27 TAS3 Ar-chitectureMUST be failsafe ie fail-ure shouldnot leadto securitybreach D12-28 TAS3 Ar-chitectureMUST beavailable D12-29 Implementa-tion MUSTcorrectlyimplementTAS3 Archi-tecture D12-210 TAS3 MUSTappear tothe usersto workcorrectly D12-211 The func-tionality ofTAS3 mustbe trans-parent tothe users(user cansee what isgoing on) D12-212 TAS3

MUST becomprehen-sible to theuser Theuser MUSTbe able tounderstandwhat hashappenedwhat shouldhave hap-pened andwhat willhappen D12-213 TAS3 MUSTbe easy touse D12-214 TAS3 MUSTappear tothe user tobe privacyprotective D12-215 TAS3 MUSTmake it pos-sible to holdpeople andcompaniesaccountablefor the ac-tivities withrespect topersonaldata D12-216 TAS3 MUSTmitigaterisks or pre-vent risksto the trustand secu-rity of thearchitecture D12-217 TAS3 MUSTprovide anuntamper-able audittrail D12-218 Authentica-tion in TAS3

MUST becredible D12-219 Authoriza-tion in TAS3

MUST becredible D12-220 TAS3 MUSTguaranteeonly au-thorizeddisclosuresand actions D12-221 TAS3 MUSTimplementdata pro-tectionlegislation intechnology D12-222 TAS3 MUSTpermit ac-cess to theaudits forlegitimateauthorities ifthis is legallynecessary D12-31 ProcessdesignersSHOULD begiven toolsto define(graphical)modelsof theirbusinessprocessesincludingthe inter-actions ofthe processwith externalcompo-nents ieweb ser-vices andhuman ac-tivities (webinterfaces)and otherbusinessprocesses D12-32ServiceprovidersMUST beable toautomati-cally trans-late theirsecurity-aware pro-cess modelsinto an ex-ecutableform andinto securityparametersconfiguringsome partsof the trustand securityinfrastruc-ture D12-33 UsersMUST havean interfacewhere theycan seetheir presenttasks inbusinessprocessesand thepresent sta-tus of theprocessesthey arecurrentlyinvolved D12-35 ProcessdesignersMUST beable tospecify theassignmentof tasks toactors in abusinessprocess in asufficientlyabstractflexible andsecure wayusing rolesfor groupingtasks andresponsibili-ties D12-36 Businessprocessproviders(in generalcoordinatorsof a complexservice)MUST beable to con-trol whoperformsa task bybinding au-thorizationto performa task andaccessnecessaryresources toroles D12-38 ProcessdesignersMUST beable to spec-ify mutualexclusionbetweenroles in thescope of aprocess D12-310 PermissionsSHOULDonly bevalid whenneeded D12-315 Adaptionof a processmust resultin a processwith guar-anteeingthe samequality levelof security D12-41TAS3 MUSTbe ableto enforceuser-centricpolicies oninformationgatheredfrom datasubjectsand on ag-gregatedinformationsets D12-42Distincttransactionsor execu-tions of abusinessprocess thattakes placein the TAS3

environmentMUST beindistin-guishablefrom oneanother D12-43It MUST bepossible todemonstratethe complexsecurity andtrust fea-tures of theTAS3 func-tionality andconcepts ina compre-hensible wayfor lay users D12-44 TAS3

serviceprovidersMUST beable to provethat theyprocessedthe infor-mation andservicesin accor-dance tothe requiredpolicies Theproof MUSTbe usable incourt D12-45Each TAS3

actor (ieserviceprovideror serviceconsumer)MUST pro-cess theinformationin compli-ance withthe ap-propriatepolicies D12-46 Inexceptionalsituationsan identifiedTAS3 actorneeds tobe grantedaccess toinformationto whichaccesswould be de-nied undernormal cir-cumstancesSuch func-tionalityMUST beoffered byTAS3 D12-47 TAS3

serviceconsumersMUST beable todiscoverserviceprovidersthat committo meetingtheir require-ments andpolicies D12-48TAS3 discov-ery serviceand policymanage-ment systemMUST beuser friendlyand easyto configureand use D12-49TAS3 discov-ery serviceMUST takeinto accountthe trust andreputationscore of bothservice con-sumers andproviders D12-51 The trustmanage-ment systemSHALLanswertrust policyevaluationrequestswhich canuse differentsources oftrust D12-52 The trustmanage-ment systemSHALLdefine acombinedtrust policylanguagethat allowsuser toformulatetrust policiesbased oncredentialsreputationsand eco-nomicalinformation D12-53The trustmanage-ment systemSHALLprovidea reputa-tion basedtrust man-agementservice D12-54The trustmanage-ment systemSHALL sup-port thegathering ofreputationfeedbackinformation D12-55The ap-plicationbusinessprocessSHOULDprovidea trustfeedbackopportunity D12-56The trustmanage-ment systemSHALLprovide acreden-tial basedtrust man-agementservice D12-57The trustmanage-ment systemSHALL pro-vide a keyperformanceindica-tor basedtrust man-agementservice D12-58The trustmanage-ment systemSHOULD beextendablewith noveltrust metrics D12-59 The trustmanage-ment systemSHALL pro-vide trustpolicy for-mulationsupport D12-511 The legal-contractualframeworkSHALLsupportfeedbackdata usepolicies D12-71 A usersometimesneeds tobe able toauthoriseanother useror service toact on hisbehalf D12-72 Userssometimesneed to beable to signdocumentsusing theirroles D12-73 The usermust be ableto prove whohe is to anyservice andalso be surethat he istalking tothe correctservice D12-74 A usermay needto presentseveral au-thorisationcredentialsin order toobtain aservice ega credit cardand a clubmembershipcard D12-75 Usersshould onlyneed toprovide theminimum ofcredentialsthat areneeded toobtain aservice andno more D12-76 Users musthave the au-thorisation toperform anyaction D12-77 Usersshould beable to dy-namicallyset theirprivacypolicies D12-78 Differentserviceprovidersshould notbe ableto colludetogetherto deter-mine who apseudony-mous user iswithout theuser2019sconsent D12-79 Credentialsshould berevocable D12-710 Credentialsshould betargetableto a specificrelying party D12-712 The systemmust beable to pulladditionaluser cre-dentials ondemandasrequired D12-713 The systemmust be ableto determinewhere to pulladditionalcredentialsfrom D12-714 One serviceprovidershould beable to sub-contract(delegate) toanother ser-vice providerto get workdone onbehalf of theoriginal user D12-715 Usersshould beable to pushtheir cre-dentials tothe systemdynamicallywhen moreare needed D12-716 User shouldbe able touse differentpseudonymsin order toprotect theirprivacy D12-717 Credentialsshould be in-crementallyreleasedas trust isestablished D12-718 A serviceprovidershould notbe able tolink togetherthe sequen-tial requestsof a userwithout theuser2019sconsent D12-719 Serviceprovidersshould beable to up-date theirpolicies dy-namicallywithout hav-ing to bringdown thesystem D12-720 Serviceprovidersshould beable to dis-tribute policyadministra-tion betweenmultiple ad-ministrators D12-721 The systemneeds tobe resilientto fraud ormistakes byusers andadministra-tors D12-723 The au-thorisationsystemneeds to beable to makedecisionsbased onthe currentstate of theapplica-tion andorsystem D12-724 The au-thorisationsystemshouldsecurelyrecordauditthe deci-sions thathave beenmade ina tamper-proof andconfidentialmanner D12-725 Auditingneeds to bedynamic andadaptive tochanges inthe systemandor envi-ronment D12-726 A user mustprovide con-sent for theuse of hisprivate dataand creden-tials D12-727 Sensitivetasks mustbe splitbetweenmultipleusers D12-81 The pilotsMUST havea gatewayto accessthe TAS3

core compo-nents D12-82 LegacydatabasesSHALL beable to pro-vide theirdata andservice toTAS3 D12-83 An end-userSHALL beable to ac-cess TAS3

functionalitythrough abusinessprocess andan accord-ing webfrontend D12-84 An enduser SHALLbe able toaccess TAS3

servicesthrough aspecial TAS3

genericclient D12-86 An end userSHALL beable to storeand modifyits data in arepositoryfor per-son relateddata Thisrepositoryhas to bereachablein a TAS3

secured andtrusted way D12-914 Back of-fice servicesmust be in-visible to theuser D12-916 Datawithin theecosystemSHOULDnot becopied orduplicatedit should bestored onceused manytimes D12-101 The TAS3

architec-ture MUSTsupportperpetual(ie event-driven peri-odical) andautomatedcompliancetesting ofservices D12-102 The TAS3

infrastruc-ture SHALLdetect ser-vice failuresin grantingor denyingaccess toresourceswith respectto theirmanifestedpolicies D12-103 In a TAS3

choreogra-phy errormessagesreturnedafter a re-quest of aresource(eg ac-cess deniedmessage)MUST beidentifiableas sucheg througha specialflag in themessageheader D12-108 Servicesthat are toparticipatein a TAS3

choreogra-phy MUSTbe accom-panied withmodels de-scribing theircharacteris-tics D12-109 All ser-vices willingto partici-pate in aTAS3 chore-ographySHOULDbe validatedagainst theaccompany-ing modelsD12-1010-AzFailNotifNetOps

WP2 WP10 D21 sec 61 Dash-board D24 sec27 Realization ofthe Audit and Dash-board Function

The primary means of reporting authorization fail-ures is via Audit Bus The Trust Network operatorshould listen to these events

Version 20

D12-1011-AzFailNotifTrust

WP2 WP10WP5

D21 sec 61 Dash-board D24 sec27 Realization ofthe Audit and Dash-board Function

The primary means of reporting authorization fail-ures is via Audit Bus The Trust and Reputation In-frastructure should listen to these events

D12-1012-ModelIf

WP2 WP10 Typical Service Provider that joins Trust Network willdescribe its services in terms of (i) SAML Metadata(ii) Registration of EPR and (iii) WSDL

Currently (2010) no facility to register or distributeWSDL is provided

D12-1013-ModelAz

WP7 WP10WP2

Current (2010) we do not adequately capture au-thorization model It is expected that the WP10 testcase generation activity can use the actual policiesto derive the test cases No facility to register autho-rization model is provided either

D12-121-Grok

WP11 na This is not a requirement addressable in architec-ture

In general TAS3 should provide training so thateverybody can comprehend it

D12-122-DokuAc

WP11 na Project requirement not an architecture require-ment

Ideally should be addressed by the disseminationwork package (WP11)

D12-123-WorkLoad

WP13 na Project requirement not an architecture require-ment Fundamentally this is a project managementissue

D12-124-Escalate

D12-125-DokuCVS

WP12 WP13WP8 WP9

na Project requirement not an architecture require-ment Fundamentally this is a project managementissue

D12-126-ProjComm

D12-127-CompChk

WP12 WP8WP9 WP10

na Project requirement not an architecture require-ment Fundamentally this is an integration issue

WP10 work although focussed on the On-linetesting can provide some regressing testing frame-work as well (for module developers to use beforethey submit the modules to certification)

D12-128-CtlEnv

WP12 WP10 na Project requirement not an architecture require-ment Fundamentally this is an integration issue

WP10 needs to define what are the controlledproduction environements that software should betested against

Version 20

D12-129-MadTest

WP10 WP12WP8 WP9

na The On-line Compliance Testing functionality re-quires negative testing and sometimes the only wayto achieve this is to have in every component aknown triggerable way to fail

D12-1210-MultiEnv

WP12 WP10 na WP10 test suites should specify the secnariosWP12 should be ready to support these scenarios

D12-1211-KickStart

WP12 na The ability to recreate test conditions is immenselyimportant Some techniques that can be used to-wards this end are Kick Start and instantiation ofcanned virtual hosts

D12-1212-SubInst

WP8 WP9WP12

na Sub-component installation scripts are good prac-tise as they document what is component specific

D12-1213-Vfy

WP2 Sec 6 Oversight andMonitoring A22Liberty ID-WSF

User triggered verification of systemrsquos correctfunctioning depends on every system compo-nent implementing a ldquodry-runrdquo feature such asID-WSF iexclProcessingContextiquest urnlibertysb2003-08ProcessingContextSimulate SOAP header Fur-ther assurance of correct functioning can be ob-tained from the Dashboard

D12-1214-Case

WP8 WP9WP12 WP10WP3 WP7WP2 WP5

na Provision of specific evil test cases is mainly respon-sibility of the particular software developers How-ever designers of the business processes iden-tity management architecture and reputation arewell positioned to generate particularly insidioustest cases and simulated attacks These resourcesshould be used to make sure all known attacks arecovered in the testing

D12-1215-Valid

WP2 WP10 Sec 6 Oversight andMonitoring

User triggered validation can be implemented tosome degree using the Dashboard However itdoes not seem feasible to allow each and every userto audit everything about the system at will There-fore beyound the Dashboard functionality mostusers will have to content themselves with trustingthe Trust Network level audits and On-line Compli-ance Testing

D12-1216-OnlineTst

WP10 WP2 Sec 61 On-lineCompliance Test-ing A22 LibertyID-WSF

Continuous On-line testing is principally supportedby ldquodry-runrdquo features of the architecture The ac-tual implementation of the testing is carried out byWP10

D12-1217-Doku

WP8 WP9WP7 WP2

na The architecture will strive to deliver most clear doc-umentation feasible

D12-1218-ExtDoku

WP12 ZXIDetc

na To the extent that the ldquoexternalrdquo dependencies areactually projects of TAS3 participants we expectthem to deliver documentation up to the projectstandard

Version 20

D12-1219-ReadersGuide

WP8 WP9 na The architecture will attempt to implement a readerrsquosguide but this quite likely is not going to be compli-ant with this requirement neither should it be

D12-1220-Train

WP11 WP2 GAP Training sessions about architecture should havesuccinct materrial GAP This material does not ex-ist yet

D12-1221-ChgMgt

WP12 WP8WP9 WP13

na Architecture documents are revision controlled un-der cvs tas3repoarch Further any externally re-leased copy has a two digit release numbers thatadvances for every minor release

D12-1222-Plan

WP8 WP9WP7 external

na The planning exercise is not in scope of the archi-tecture

D12-1223-BugTraq

WP12 na Bug tracker is not in scope of the architecture

D12-1224-RelRepo

WP12 na Release repository is not in scope of the architec-ture

D12-1225-IfCat

WP12 WP2WP8 WP9

GAP Architecture will contribute to the interface catalogin due time There will be additional interfaces de-fined by WP8 and WP9 that are not in scope of thearchitecture WP8 and WP9 will contribute theseseparately

D12-1226-RefImpl

WP2 WP4 GAP D43 Architecture plans to provide a reference implemen-tation for realistic online testing This is not availableyet Deliverable D43 provides a simulation of thefunctionality

D12-1227-ComOnto

WP9 WP2 D22 Common reference data model ie an ontology willbe delivered by the ontology activities of WP2 How-ever this model is limited to a very high level with adrill down in the authorization area until WP9 liaiseswith ontology

D12-1228-AppOnto

WP9 WP2 D22 Application ontologies and their mapping are anactive research topic of TAS3 Architecture fore-sees this as an Attribute Broker

D12-1229-MockUp

WP8 WP9WP7 WP12

na A Mock Up compenent is typically able to providestandard response irrespective of input and will actas a stand-in until the real component can be devel-oped (or is stable enough) Use of Mock-Ups is anintegration and testing strategy that allows project tostay on schedule

D12-1230-root

WP12 WP13 na Root access for key project authorsdevelopers willcertainly reduce friction and make the project moreefficient

Version 20

81 Gaps

The following table lists gaps found between requirements and the M24 edition of the TAS3 architecture Theserequirements are addressed in the M36 edition of the architecture as described

How addressed

D12-310-JITPerm

D12-311-UPAPD

WP2 GAP D41 GAP Architecture has to specify the Policy Author-ing interface

D12-312-SPManifest

WP3 WP2 GAP D21 Sec5 Using BusinessProcess Modellingto Configure theComponents D41

D12-512-TrustRank

WP5 WP2 Trust PDP D24 Sec 27 ldquoUsing Trust Scoring in Discoveryrdquoprovides the plumbing for passing the trust scoresaround

D12-711-PolMerge

D12-92-UPA

D12-96-UPADetail

WP8 WP2 Dashboard IdentityMirror

The identity mirror functionality is only partially ad-dressed by dashboard More work is needed

Version 20

D12-1012-ModelIf

More work is needed in registering and distribut-ing complete model

D12-1013-ModelAz

WP7 WP10WP2

Version 20

9 Requirements fulfilled by existing solutionsThe objective of this section is to give an overview and analysis of the existing solutions that can be used in

the development of TAS3 and those selected for use in the TAS3 project The complete list and details of existingsolutions that were considered for use by the various work packages are in Appendix D

We use tables to give an overview of the existing solutions the requirements they fulfill and the selectedsolutions For better readability we preferred to show the results in multiple tables instead of a very largetable that includes all the existing solutions and all the requirements that they fully or partially fulfill Each tablecontains a subset of the existing solutions suggested by a subset of the TAS3 work packages

The tables are organized as follows We first grouped shared solutions together and then listed in each tableall the other solutions that were considered by those work packages For example Work Package 3 and WorkPackage 7 have PERMIS as a common solution So we have included in Table 95 all the solutions suggestedby those two work packages Further Work Package 7 and Work Package 10 have common solutions Hencethese and all the other solutions used by Work Package 10 are included in Table 95 The solutions selected foruse in the TAS3 project research and development activities are highlighted with grey columns The columns ofthe compared solutions are delimited with extra white stripes

Further we noticed from the inputs of the partners that an important criteria in selecting software is the licenseconditions of the solutions The TAS3 partners prefer open source solutions or open standards when they areavailable In order to make these choices visible we also inicated whether the given solution is open source (O)proprietary (Pr) or subject to both here called a dual licensing system (D)

Some solutions only partially fulfilled a given requirement In case of partial fulfillment of a requirement weused (P) If the requirement is fulfilled by the solutions then we denoted that with an (F) No indication meansthat the solution does not fulfill the requirement in any way

In each section we also included a summary of the justifications for the selected solutions The detailedjustifications with additional information on the solutions are included in Appendix D

91 Existing solutions considered and selected by WP 3 7 and10 (CNR)

Existing solutions considered by work packages 3 7 and 10 are as follows

bull s1 Intalio Designer BPMS and Tempo

bull s2 Oracle BPM-Suite

bull s3 IBM Web Sphere Integration Developer

bull s4 ActiveBPEL Community Edition Engine

bull s5 jBPM

bull s6 PERMIS

bull s7 Trustbuilder2

bull s8 Shibboleth software from Internet2

bull s9 SAMP PHP

bull s10 ZXID

bull s11 Lasso

bull s12 Authentic

bull s13 WS Guard

bull s14 TAXI

Solutions s1 through s5 can all be used for business process modeling Intalio Designer BPMS is the solutionof choice since it is open source software it provides graphical modeling as well as a process execution engineand integrates both parts and the process modeling tool together is a very comprehensive and comfortablyusable tool

Version 20

PERMIS (s6) are going to be used by both WP 3 and WP7 PERMIS is selected because it is open sourcesoftware is modular allows plug and play with an XACML PDP and has more required functionality than anyother package

Trustbuilderv2 (s7) is selected because it is a configurable open source solution for trust negotiation It iswritten in Java and allows plugin modules for policy evaluation and negotiation strategy It allows credentials andpolicies to be written in any language providing the correct plugins are available Whilst although WP7 activitieswill probably include writing some plugins in order to support the policies and credentials of TAS3 neverthelessthey anticipate that the TrustBuilder2 infrastructure will support this

Solutions s8 through s10 provide SSO functionality The selection has not yet been finalized since it requiresfurther investigation ZXID has already been selected for the project and also facilitates SSO The selection isnevertheless not exclusive ZXID is selected because it is written by a SAML ID-WSF and XACML insider itis interoperable it is SAML 20 and IDWSF 20 certified in its commercial (Symlabs) incarnation it is developedby a TAS3 contributor so ensures good support ZXID will be used by both WP7 and WP10 in their researchand development activities It is also included in the architecture

WS Guard (s13) and TAXI (s14) are both developed by CNR as a result of research in related areas Thereare no comparative tools performing the same functionalities

Solutions s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14Access O Pr Pr Pr O O O O O O O O O OD12-31 F F F F FD12-32 F F F F PD12-33 F F F FD12-34 P P P P PD12-35 PD12-36 PD12-71 PD12-72 PD12-73 F FD12-76 FD12-77 FD12-79 FD12-710 FD12-712 PD12-713 PD12-714 PD12-715 PD12-716 F PD12-717 FD12-718 F FD12-721 PD12-723 PD12-724 FD12-726 FD12-101 F FD12-102 F F F F FD12-108 F F F

Table 91 Existing solutions considered by WP3 WP7 and WP8 and the related TAS3 requirements

92 Existing solutions considered and selected by WP 4 and 5

Existing solutions considered by work packages 4 and 5 are as follows

bull s15 KU Leuvenrsquos Demonstrator Framework

bull s16 Belgian e-ID Card

Version 20

bull s17 Encryption Algorithm AES

bull s18 Tulip Trust Management

bull s19 Postgre SQL

bull s20 ORACLE

bull s21 SunXACML

bull s22 Trust Policy Wizard

The KU Leuven Demonstrator Framework (s15) was selected because it is a proven technology that caneasily be extended During the first year of TAS3 the demonstrator framework has been extended with supportfor complex business processes the break-the-glass function and advanced policy enforcement The Belgiane-ID Card (s16) is used as the authentication token that has the highest level of assurance that is currentlyavailable in the consortium And AES (s17) is a standard encryption decryption algorithm with currently provenstrength

Feedback data required for Reputation Trust Management (RTM) is typically stored in a database manage-ment system such as Oracle Database (s20) or PostgreSQL (s19) The key advantage of the RTM system inTAS3 is that reputation is computed directly inside the database Existing database management systems donot support this computation Compared to Oracle Database PostgreSQL is open source and thus allows forthe necessary modifications The other existing solutions had no alternatives with respect to the necessary re-quirements of these work packages Compared to other existing CTM systems TuLiP Trust Management (s18)excels in key aspects for TAS3 especially with respect to flexibility of the syntax user autonomy and automationThe Trust Policy Wizard (s22) is selected because providing a wizard is a powerful yet straightforward way ofsupporting user selected policies The work package team does not exclude the possibility for more integratedsolutions such as eg natural language policy editors as the project proceeds

SunXACML was selected because it is a well known open source XACML implementation uses an OASISstandard policy language supports a wide range of access control policies and can be combined with PERMISwhich will be used and further developed by work packages 3 and 8

Solutions s15 s16 s17 s18 s19 s20 s21 s22Access O D O O O Pr O OD12-21 FD12-25 FD12-26 FD12-37 FD12-105 FD12-121 FD12-56 FD12-53 F FD12-54 F FD12-51 FD12-76 FD12-59 FD12-42 PD12-43 PD12-44 PD12-45 PD12-46 FD12-48 PD12-49 P

Table 92 Existing solutions relevant to WP4 and WP5 and the requirements the solutions fulfill

Version 20

93 Existing solutions considered and selected by WP 8

Existing solutions considered by Work Package 8 are as follows

bull s23 FEDORA

bull s24 DSpace

bull s25 CDSWare

bull s26 EPrints

Among existing open source repositories Fedora (s23) was selected because it is a repository that can becompletely integrated in a SOAHence all functionalities of the repository are accessible through a SOAP orREST based web service interface and it is an open source solution with a strong community behind it

Solutions s23 s24 s25 s26Access O O O OD12-86 F P P P

bull s27 Saturn

bull s28 ePars

bull s29 OPUS

bull s30 Mahara

bull s31 PebblePad

bull s32 Kenteq Competent Web Application

bull s33 Personal Health Record (PHR)

bull s34 Patient Information Location Service (PILS)

The demonstrators by definition take over existing software from their domain partners The UK employabilitypilot relies on Saturn (s27) ePars (s28) OPUS (s29) Mahara (s30) and PebblePad (s31) Saturn (s27) is thedatabase which is the source of student data as held by the institution ePars (s28) allows access to Saturn datawithout having to access Saturn directly which WP9 in Nottingham would not be allowed to do for demonstrationpurposes OPUS (s29) is an open source placement co-ordination package available to WP9 in NottinghamMahara (s30) was selected by the team because out of the over 80 ePortfolio systems in use in the UK at themoment not all are free and not all are web-based Many ePortfolio systems remain under institutional controlMahara is open source and WP9 Nottingham are in contact with the developers They are also part of a strongcommunity of interest that is currently developing Mahara which can provide further support in its use for workplacements PebblePad (s31) is a Web-based learner-controlled system The system supports exports in avariety of standards including UK-LEAP and IMS ePortfolio Futhermore by using PebblePad the Nottinghamteam will be able to access candidates who have established ePortfolios using this system and offer a richsource of demonstrator data WP 9 Nottingham team also has a good relationship with the company throughother project work

The WP9 Netherlands team working on employability will build upon the Kenteq Competent Web Application(s32) Solutions comparable to Competent are often embedded in software for internal HR processes Com-petent supports the APL and profile matching process as such independent from the organisation or individualwho applies for an employability service There are no other off-the-shelve application available who supportsemployability processes The application is in English and in Dutch which is also an advantage for the NLdemonstrator

The WP9 healthcare demonstrator will rely on the Custodix PILS (Patient Information Location Service s34)This service integrates a medical data viewer with a system for distributed search of medical information It will be

Version 20

used in both the personal health record use case track (cf Deliverable D91) and the backup pilot track involvingthe summary record (cf Deliverable D14) as a front-end for locating (medical) information on TAS3 enableddata providers The Personal Health Record (PHR - s33) implementation required for the WP9 scenarios wouldoriginally be provided by MediSoft however this partner has left the consortium No replacement has beenofficially appointed yet (candidates are available)

The solutions used by WP 9 will be used to create the demonstrators that will be used to validate some of theTAS3 requirements in the application domain and will also generate further requirements to the TAS3 projectHence in its current state existing solutions do not fulfill any of the requirements of the TAS3 project

95 Existing solutions considered and selected by WP 10 (UNIZAR)

bull s35 EyeTracker

bull s36 Click Tracks Web Tracks

bull s37 Structural Modelling Tools (EQS PLS SPSS)

These are the standard tools used by and accessible to the UNIZAR team

Solutions s35 s36 s37Access Pr Pr PrD12-104 FD12-105 F F FD12-106 P P F

Solutions s38 s39 s40 s41 s42 s43 s44 s45 s46 s47 s48 s49 s50 s51 s52Access Pr O O O O Pr O O O Pr O D O O OD12-121 F F F F FD12-122 F F F F F F F F F F F FD12-123 F F F FD12-124 F F F FD12-125 F F F F F F F F F F F FD12-126 F F F F F F F F F F F F FD12-127 F FD12-1211 F FD12-1215 F FD12-1217 F F F F F F F F F F F FD12-1218 F F F F F F F F F F F FD12-1219 F F F F F F F F F F F FD12-1220 F F F F FD12-1221 F F F F F F F F F F F FD12-123 F F F FD12-1224 F F F F F F F F F F F F FD12-1225 F F F F F F F F F F F FD12-1227 F F F F FD12-1230 F F F F F F F F F F F

Table 95 Existing solutions considered by WP12 and the related TAS3 requirements

Version 20

Common documentation repository

bull s38 Jira (proprietary)

bull s39 Concurrent Versions System CVS (open source)

bull s40 Subversion SVN (open source)

bull s41 MediaWiki (open source)

bull s42 DokuWiki (open source)

bull s43 Confluence (proprietary)

bull s44 Redmine (open source)

bull s45 Trac (open source)

bull s46 GIT (open source)

bull s47 ActiveCollab (proprietary)

bull s48 Semantic Media Wiki (open source)

bull s49 OntoPrise Onto Studio (dual licence)

Central issue and defect tracking

bull s50 BugZilla (open source)

Continuous integration incl testing

bull s51 Hudson (open source)

bull s52 Nagios (open source)

Data type level and other conceptual documentation

WP12 provides the coordination and services to integrate the software modules produced by the security andapplication work packages Because the complete constellation of components (web services) must meet specicrequirements that directly reect on the individual components WP12 also has a stake in guiding and monitoringthe WPs that produce the componentsThe solutions listed above are under consideration to support the guidingand monitoring activities This requires extensive evaluation of the existing solutions which is currently underway The likely candidates are denoted with an asterisk

97 Existing solutions considered and selected by WP 2 (VUB)

The only existing solution considered by Work Package 2 (VUB) is as follows

bull s53 DOGMA Studio Workbench

DOGMA Studio Workbench is the only tool that suppor ts DOGMA inspired ontology and it fulfills the Require-ment D12-223

Version 20

10 Requirements that call for new solutionsIn this section we list the future activities of all partners to fulfill the requirements which are not addressed

by existing solutions but are imminent to the TAS3 project Here again a difference is to be noticed with WP6and WP9 WP6 depends on the activities of other work packages to fulfill its data protection requirements Wehave been working closely with WP6 to refine the requirements to include legal and policy requirements or togenerate new requirements for these These refinements in their initial form now included in D14 Section 6 [22]and will have to be discussed with all partners in the depth before the next iterations of these deliverables

Similarly the demonstrators in WP9 are in the process of preparation in their application domains Henceupon our request they have listed an outline of their general activities with respect to their application domainsOnce the application domain activities are fixed we will expect them to review their requirements according tothe conditions of their application domains Resulting from those WP9 will also list activities for the fulfillment ofthose application domain specific requirements Once the demonstrators are running WP9 will also generatenew requirements for the TAS3 which will have an effect on all the work packages If these requirements aregenerated before the second and final iteraction of D12 we will capture those new requirements and trace theireffects on the existing requirements

In this iteration of the deliverable we are missing a concretization of the validation activities Although sug-gestions for activities for validating the fulfillment of requirements were suggested by almost all work packagesthese suggestions are very general This is partially due to the fact that the requirements are at such a highlevel that they still need to be refined into verifiable sub-requirements which can then be validated But thegap analysis and the interaction analyses would have been difficult to execute with requirements of very highgranularity This is a tension between the need for a high-level analysis and low-level analysis necessary whendoing requirements analysis We hence conclude that the validation activities have to be revisited once therequirements are refined and consolidated

101 Activities of WP2

WP2 partner for architecture has not submitted these activities Sampo will map the requirements to the archi-tecture next week

D12-223 will be fulfilled by applying the DOGMA-MESS methodology to the TAS3 domain We firstplan to develop an upper ontology to allow the different topics (ie Security Privacy andTrust) to be modules within the same ontology We are then going to use IT standards todevelop the Upper Common Ontology (UCO) (as per the DOGMA methodology) We arethen going to elicitate domain specific knowledge to develop the Lower Upper Ontology andany knowledge that need to be committed to the UCO through ontology evolution

D12-34 requires an authentication component provided by WP7 and design and implementationwork in the role management component of the used BPMS (for a client component) D12-34 will be validated in the test bed

Version 20

D12-35D12-36D12-37D12-38D12-310D12-311

D12-35 through D12-38 D12-310 and D12-311 require additional research to definea security model as existing literature approaches are not sufficient andor coherent Theyrequire design and implementation work for both modeling and runtime enforcement Es-pecially D12-36 and D12-310 require research how the security infrastructure can allowa process to change permissions D12-311 requires the design of application-specific on-tologies and a policy framework applicable to PII (not WP3rsquos task to be handled in WP4) The concepts for D12-35 through D12-38 D12-310 and D12-311 will be validatedby applying them to the demonstrators Implementation will be validated by executing theseapplications in the test-bed On the one hand this is done for the original applications(including user interaction) On the other hand we will replace user interaction by mockservices and devise test-cases that run automatically

D12-36D12-37

D12-36 and D12-37 require the specification and enforcement of policies This is partlyin the scope of WP7 and the PERMIS product already fulfils the decision part of runtimeenforcement In WP3 we will have to design and implement specialized process-specificsecurity policy management Delegation (D12-37) requires (basic) usability testing Indi-vidual distinct functions (like role assignment D12-36 or delegation D12-37) will receiveunit tests

D12-39 requires additional design and implementation in the BPEL execution engine

D12-312 is best applicable to an extensive eco-system which will not be realised during the durationof the TAS3 projects Lacking such an infrastructure we will validate it using case studies

D12-313D12-314D12-315D12-316D12-317

D12-313 through D12-317 requires extra research in TAS3 on the topic secure adaptationof business processes and model driven development of policies They require the specifi-cation of changes of the process model the check if these changes are allowed in respectto several criteria (consistency as well as security related) and the migration of process in-stances Further on security specifications at the business level have to be transformed onto the technical level by generating elements of the process execution level (parts of) secu-rity policies and configuring process-specific enforcement components The results must beimplemented and validated D12-313 through D12-317 requires (basic) usability testingfor distinct components and integration testing in the WP12 testbed It will be validated byapplying them to the demonstrators as well

[danny we are missing validation activities for each]

D12-41 will be implemented based on the application independent policy enforcement point (cfwp7) This requirement will be validated during the accreditation and each re-accreditationof a TAS3 service provider

D12-42 will be implemented based on the identifier mapper that is developed within WP4 cf D42This requirement will be validated during the accreditation and each re-accreditation of aTAS3 service provider

D12-43 will be implemented based on the demonstrator framework that is developed within WP4cf D43 This requirement will be validated by implementing the demonstrators

D12-44 will be implemented based on the dashboard service (cf WP2) and the audit guard (cfWP4 D41 and D42) This requirement will be validated during the accreditation and eachre-accreditation of a TAS3 service provider It will also be validated whenever external au-dits service users or a data subjects exercise the rights given by data protection legislationnamely those referring to the openness and transparency of data and information process-ing

Version 20

D12-45 will be implemented based on the consistent business processes cf WP6 WP3 and WP9This requirement will be validated during the accreditation and each re-accreditation of aTAS3 service provider It will also be validated whenever external audits service users or adata subjects exercise the rights given by data protection legislation namely those referringto the openness and transparency of data and information processing

D12-46 will be implemented using the break-the-glass mechanism cf WP7 and D43 This re-quirement will be validated during the pilots This requirement will be validated during theaccreditation and re-accreditation of a TAS3 service provider It will also be validated whileexercising the data subjectrsquos or auditorrsquos right to detail the steps used while processing therelated information

D12-47 will be implemented based on the trust and privacy policy negotiation mechanism that willbe developed by WP4 in collaboration with WP2 WP5 and WP7 and in compliance withWP6 This TPPN mechanism requires new research This research has already been boot-strapped within FP7PrimeLife This requirement will be validated during the accreditationand each re-accreditation of a TAS3 service provider It will also be validated wheneverexternal audits service users or a data subjects exercise the rights given by data protectionlegislation namely those referring to the openness and transparency of data and informationprocessing

D12-48 will be implemented in the demonstrator framework of D43 using the input of WP10 onusability aspects This requirement will be validated by the users during the different pilots

D12-49 will be implemented based on the trust and reputation scoring mechanisms developed inWP5 This requirement will be validated during the accreditation and re-accreditation of aTAS3 service provider

D12-51 will be fulfilled by a Trust PDP component developed within WP5 The Trust PDP will answertrust policy evaluation queries by calling specialized trust services facilitating their interac-tion and combining their answers The Trust PDP shall support XACML requestresponsecontext for trust evaluation queries to offer a standardized interface Note that the use ofXACML contexts does not imply the used of the XAMCL policy language the Trust PDPwill use a trust specific policy language The XACML request context is flexible enough toembed the trust specific information and policies The Trust PDP will be implemented byextending a standard XACML PDP

D12-52D12-58

will require research on flexible integration of different forms of trust management Thisshould result in an integrated trust architecture The Trust PDP forms the interface to thisarchitecture

D12-53 will require research on flexible behavioural policies and efficient evaluation methods forthese policies The results of this research will be incorporated in a Reputation Trust Man-agement Engine built around a relational database

D12-54 A Trust Information Collection Point will be created which stores authenticated feedbackand makes it available to the reputation based trust service Ensuring authenticity of thefeedback will need to be supported by the feedback procedure in the application businessprocess (see requirement RA-1)

D12-55 will be fulfilled by the TAS3 dashboard which provides a trust feedback form This feedbackform gives the user an opportunity to rate his or her satisfaction with the current processexecution

Version 20

D12-56 will be fulfilled by the CTM service which will be built around the TuLiP TM system and usingthe Credential Verification Service developed by WP7

D12-57 will be fulfilled by the KPITM service This component gathers and combines several KPIfactors from KPI factor providers eg [Google Analytics]

D12-59 will be fulfilled by an enhanced trust policy wizard which adds support for structural trustpolicies and novel trust metrics to the exitings trust policy wizard

D12-511 will be fulfilled by the contractual framework (WP6)

D12-510 will be fulfilled by the TAS3 authentication framework (WP7)

The various activities will be validated by experiments on the demonstrator test-beds Testing realistic use casescenarios will evaluate the effectiveness and flexibility of the Trust language and architecture components suchas the Trust PDP and TM services End user experiments will validate the policy wizard and the usability of thefeedback mechanism and understanding of the trust policies ie do they produce the expected results

WP6 is both a horizontal and vertical project within TAS3 The vertical aspects are the definition of legal require-ments and the creation of contractual elements TAS3 cooperation with other groups in these vertical aspectsis to assure that we are bother reviewing legal requirements that address all needs and functions as well asdrafting contract elements that support all roles and business needs

The horizontal elements of TAS3 are much more difficult to define in terms of deliverables at any point in timeas they are part of an iterative process This is the refinement of understanding how law policy and technologyinteract where law supplements policy and technology where technology supports law in logs or audit andwhere policy and technology are bound by legal obligations on the parties

In terms of process improvement to achieve these ends and further unify function of TAS3 as a whole WP6is working with the requirements team in developing the questions that further refine the requirements and alsoworking more closely with the demonstrator projects to assure that as questions arise in developing imple-mentation and deployment strategies legal questions are addressed and various options of law and policy arepresented

With Technical teams WP6 operates more as an on-demand resource While we provide requirements docu-ments and templates as resources our ongoing functions are more geared to helping in arriving at consensus intechnical development options where issues of how to achieve legal compliance or definitions of what is legallyrequired to be compliant are at issue As in many legal related issues these are often processes of interpretationand balancing

D12-71 requires enhancements to the delegation service of PERMIS in order to supporta) the delegate pulling his credentials from the delegation serviceb) the delegator pushing his credentials to PERMISc) credentials in SAML format

D12-72 requires design and implementation from scratch

D12-74 requires enhancements to the authorization infrastructure to support the linking of creden-tials from multiple providers when the user is known by different IDs at the different providers(design and implementation)

Version 20

D12-75 will be fulfilled by additional enhancements to the SAML protocol and subsequent imple-mentation

D12-77 requires design of a GUI for setting a privacy policy and a means of sticking this privacypolicy to the users PII

D12-78 may be impossible to fully support in technology May ultimately require legal policies andprosecutions to stop this ie D12-727 Technology can only go so far such as ensuringdifferent identifiers are used for the same user at different SPs We will investigate howmuch can be supported by various means

D12-79 requires full support for revocation adding to PERMIS Note that SAML based protocolscannot support this requirement so it will need enhancements to SAML if this is to be usedfor credentials

D12-710 requires enhancements to credential issuer to insert the target field and to PERMIS tocheck the value of this field in the credentials that it validates

D12-711 requires a new authorization component the Master PDP to be designed and built

D12-712 whilst PERMIS already has the capability of pulling multiple credentials from multiplesources the PEP needs to trigger it at appropriate times to do the pulling The designand implementation of this triggering mechanism is needed

D12-713 requires the PEP to tell PERMIS where to pull the credentials from

D12-714 requires the same enhancements as D12-71

D12-715 requires support at the application level for the pushing of credentials

D12-716 will need designing to ensure that all credentials can be tied to the pseudonyms

D12-717 may be supported by the TrustBuilder2 package We will need to investigate this and mayhave to either edit this package or write our own

D12-719 requires enhancements to the PERMIS package to support the dynamic changing of poli-cies

D12-720 requires enhancement to PERMIS to support multiple policy administrators

D12-721 requires validation of and possible enhancement to PERMIS existing support for separationof duties policies

D12-722 needs BTG policies to be defined and the authorization infrastructure to support them

D12-723 needs the PDP to support state based decision making This can be engineered throughthe introduction of an application independent PEP and obligations

D12-725 will be fulfilled through additional development of the PERMIS package

D12-727 will be fulfilled through additional developments of the SAML package andor legal policiesin WP6

Requirements D12-81 D12-82 D12-83 D12-84 D12-85 will be fulfilled through the implementation ofsoftware components These will be validated using various testing methods which are mentioned in the activi-

Version 20

ties below

D12-81 Implementation of two gateways We call this gateway on requester side Service RequesterADPEP On provider side it is called Service Responder ADPEP The two gateways will beimplemented using the SOA (Service Oriented Architecture) approach For testing purposesthe Intalio BPEL engine on one side and the Fedora repository on the provider side will beexemplarily integrated

D12-82 This will be done by the so called TAS3 Apache module Risaris is working on this Besidethe Fedora reference repository Risaris provides other legacy databases to function as adata provider They will test this component by replacing an existing Fedora repository withtheir legacy database combined with the RISARIS SOA gateway

D12-83 The component which will allow this interaction is called Intalio BPEL service interface Thereference BPEL engine is from our partner Intalio On requester side we have to adaptthe Intalio BPEL engine so that it can be easily call TAS3 secured services Well test thisfunctionality by demonstrating 4 use cases Creating (ingesting) a new ePortfolio modifyingthe ingested ePortfolio deleting the ePortfolio and reading it

D12-84 The generic client is based on the XForms provided by the Intalio BPEL engine In thegeneric client we will integrate those XForms so that they can be used without the IntalioBPEL engine in a more generic way In a later phase of the project well replace the BusinessProcess Engine by the generic client to test its functionality

D12-85 The special database to provide this policy management functionality is called ADPEPDatabase University of Nottingham is working on this They plan to test the functional-ity within the demonstration of the CRUD use case crating reading updating and deletingan ePortfolio or eHealth data

The validation of the fulfilment of the requirements will be achieved through executing the demonstrators Atesting program will be developed in collaboration with WP10

The activities of Work Package 9 will support validation of the requirements fulfillment activities of the technicalWPs WP9 is not building the TAS3 architecture rather WP9 is providing a realistic environment in which it canbe tested Our requirements come from the user viewpoint and need to be taken into account by all other WPs

To fulfil the overall requirements of WP09 the NL employability UK employability and eHealth demonstratoractivities need to take the following set of steps

bull Scope the domain and establish a baseline NL Employability demonstrators will be carried out in thescope of the scenarios described in D14 13 APL and 14 Mass layoff UK employability demonstratorshave decided to focus on data transfer to support education in employment to be detailed in the next it-eration of D14 The eHealth pilot focuses on exchange of medical information and patient empowermentwithin the context of Continuity of Care as described in D11

bull Identify a specific area or subset of the domain where TAS3 could be usefully implemented The demon-strator cannot engage with the whole domain at once For the NL employability demonstrator it is possibleto identify a smaller area where the processes described in D14 13 APL and 14 Mass layoff can besupported by and offer a test for the TAS3 system The UK employability demonstrator will in the first in-stance concentrate on data exchange to support student work placement TAS3 enabled data exchangewithin the eHealth domain will be demonstrated in the context of the summary record (in which healthcare professionals are the main actors) and the Personal Health Record (in which the patient takes acentral role)

For all three demonstrators WP9 will establish and engage contacts who will be willing to take part in thedemonstrator activity Once a subset of the domain has been identified organisations and individuals

Version 20

who are able and willing to take part in a demonstrator need to be identified and briefed about the projectAny necessary risk assessment for their taking part in a demonstrator needs to take place at this stage

bull Work with these contacts to detail scenarios for demonstrator activity Existing as is and to be scenariosneed to be agreed in collaboration with demonstrator partners

bull Investigate existing systems and interactions An understanding of how existing systems function andinteract is needed also any modifications needed to support web services and interoperability (neededfor D12-915)

bull Research additional systems that might be needed to support the scenario Alternative systems (egePortfolio systems) may need to be examined

bull Define data flows and formats (needed for D12-915)

bull Set up any new interoperability and data exchange between systems (needed for D12-915)

bull Create any necessary hooks or feeds for the TAS3 architecture

bull Refine use cases This may be necessary following an assessment of the technical feasibility of joiningsystems and implementing the TAS3 architecture

bull Assist with integration of TAS3 functionality into existing systems and test that the user experience will beacceptable

bull Carry out any user training needed to conduct demonstrators this may include training in non-TAS3

systems being interfaced with

bull Conduct demonstrators implementing current versions of the architecture and systems including interimtesting and evaluation and ensuring any minor fixes are carried out

bull Evaluate overall demonstrator outcomes and feed back to development partners to inform further it-erations of development design and build This will include information about user perceptions andexpectations

In order for demonstrator activity to support the use cases to run interoperability needs to be establishedbetween the systems being used if this proves not to be possible it will be necessary to research furtheralternative systems As data is stored using a variety of formats and standards and can be held behind firewallsthere is work to be done on moving data around the ecosystem for the basic use cases which the demonstratorswill test While this is not strictly work for TAS3 it is a requirement for setting up a testbed on which TAS3 canbe demonstrated WP9 does not yet have a final list of systems to be used as this will depend on the exact setof demonstrator partners involved

To validate that requirements have been fulfilled WP9 will run the demonstrators using as-live systems andtest data based on that from real life users This activity will be used to fulfill test requirements 913 and 914

However most of the requirements of this WP will be met by activities carried out by the WPs building thearchitecture and systems for the project The demonstrator activity will be validating that these have beenfulfilled Only requirement 911 will be addressed directly by WP09 activity the remainder of the demonstratoractivities will ensure that the other requirements have been met

Version 20

D12-101D12-102D12-109

extra research on model-based automated testing of service-oriented compositions in nec-essary for the fulfillment of these requirements The results of the research will be proto-typed within the TAS3 architecture In particular our intent is to develop a prototype versionof the framework implementing the on-line testing strategy based on the manifested policiesof the services The methodology behind such framework will be supported by automaticgeneration and instantiation of test suitesIn our vision a service asking registered to a directory service will undergo two differentkinds of periodic check since the request for registration The first concerns the ability ofthe service of behaving according to its manifested policy and the second of being able tocorrectly interact with required services Nevertheless some issues have to be consideredin particular to derive a real implementation of the service and to better understand theapplicability of the framework itselfTrustable services are the ultimate goal of our research we wish to increase the interop-erability and testability of SOA by fostering the application of rigorous model based test-ing methodologies The availability of a service registry enhanced with testing capabilitiesgranting the registration only to good services should reduce the risk of run-time failuresand run-time interoperability mismatches

D12-104D12-105D12-106D12-107

will be fulfilled through the development of specific measures of end-user perceptions Tobe precise we have to develop measurement tools that contemplate the true character ofthe concepts that is measures that represent the psychological perception of the systemuser To do that we will conduct the following activities

bull Firstly measure development will be based on

ndash User test

ndash Focus groups with experts and potential end-users

ndash In-depth personal interviews

bull Secondly in order to validate the measurement tools developed by Unizar to evaluateend-user perceptions we are following the steps recommended in scientific literature

ndash Content and face validity

ndash Exploratory analysis of reliability and dimensionality

ndash Confirmatory Factor Analysis

ndash Convergent and discriminant validity

bull Finally we will apply structural modeling (EQS PLS SPSS) in order to determinerelationships among variables

bull As a consequent stage of the measurement of perceptions about trust usability andservice quality and the relationships among them an effective implementation mustbe carry on

ndash Firstly based on end-user perceptions several guidelines and recommenda-tions will be proposed

ndash Secondly if designers consider it possible these guidelines will be imple-mented in TAS3 architecture and demonstrators following user-centric criteria

D12-107 will be fulfilled according to the main accessibility guidelines (Section 508 Standards andWAI criteria) A manual or semi-automatic evaluation (eg HTML interfaces) will be devel-oped

Version 20

WP12 will be setting up the central resources required to deploy test beds using the software packages men-tioned before Actual testing will be performed on the test bed by the development partners (unit tests) andWP10 (general tests)

D12-121 D12-122 D12-1219D12-1220

Make sure that all relevant system and architecture documentation is available and acces-sible to everybody This is done by having fixed process steps checking for this

D12-123 D12-124 D12-1221D12-1222D12-1223D12-1224

Maintain close contact with WP13 project management to integrate formal software deliveryinto the integration process

D12-125 D12-126 D12-1223D12-1224D12-1225

Create and maintain central project resources to support the integration process This re-quires both system administrator resources and content moderatoreditor resources

D12-127 D12-128 D12-1210D12-1211D12-1213D12-1214D12-1215D12-1216D12-1226

Work with WP10 to establish continuous testing and integration processes on central testbeds

D12-129D12-1212D12-1217D12-1218D12-1219

Establish guidelines and rules for software developers so the delivered components can beintegrated into the process not just into the system

Version 20

11 ConclusionThe contributions specific to the final iteration of the Deliverable 12 is as follows

bull we provide an the list of WP technical requirements with including new refined (edited) and deletedrequirements in the TAS3 project after all the requirements analysis activities

bull we provide documentation of the analysis of Inter-WP requirements to consolidate the technical andlegal requirements with the architecture This work includes the development and use of an automatedanalysis tool to identify inconsistency candidates

bull we provide a mapping of global technical and legal requirements to the components of the architecturealigning all of the main artifacts developed in TAS3

We have also learned many lessons during the execution of Deliverable 12 The completion of the variousinteraction analysis activities in a distributed manner caused a great communication overhead which we had toresolve by organizing face-to-face meetings and workshop Further the interaction analysis provided the chancefor various WPs to align their work and to resolve ambiguities We are very excited about the Trac Wiki tool butwe are now aware that it is easy for partners to edit the wrong documents at the wrong time Such unexpectedediting may cause communication problems among the partners Nevertheless we have made the final list ofrequirements available on the Trac Wiki to be updated by the WPs as the project progresses Finally on a positivenote we have seen that interaction analysis is powerful in determining inter-WP requirement inconsistenciesgaps and overlaps We plan to write a second paper to follow our recently submitted paper on the requirementsengineering process in TAS3 [15]

The contribution of the deliverable in general is threefold It provides a gap analysis which was used to mapout future activities In order to complete the gap analysis in the deliverable the partners have elaborated onthe technical legal and application domain requirements of TAS3 The deliverable also provides an extensiveanalysis of the interactions of the TAS3 requirements and maps out responsibilities and necessary cooperationsfor fulfilling these requirements

More specifically in Section 3 we revisited the objectives of TAS3 and each work package For each WP westated the solved and unsolved problems that they are addressing in TAS3

In Section 4 we captured those requirements that are central and therefore of higher priority for each of thework packages We also mapped out interdependencies between work packages as stated by the partners InSection 5 those interdependencies were further elaborated from the viewpoints of the different WPs The resultsof the interaction of legal and technical requirements a novel research element in the deliverable is presented inSection 6 In Sections 7 and 7 we mapped the global and technical requirements to the architecture Overlappingand conflicting requirements as well as other inconsistencies were analyzed and refined until a consistent andcomplete set of requirements were reached

In Section 9 we listed existing solutions and the requirements they fulfill which showed both that the partnersare aware of existing solutions and their utility for their research and development activities and that there isa need for future research and development in the area of trust and security in service oriented environmentsIn Section 10 we listed the planned activities of each work package We expect partners to review this listespecially with regard to their validation activities as the project proceeds

As we advanced with the requirements of TAS3 it became evident that any further partitioning of the require-ments into functional security trust andor privacy requirements is unreasonable This is due to the fact that thisproject is about building a trusted and secure service architecture that implements the data protection principlesHence most higher level requirements are non-functional requirements that go hand in hand eg most securityrequirements also fulfill the security principle of data protection legislation Further functional requirements arede-emphasized in most of the project the objective of TAS3 is to define the security trust and privacy aspectsof communication between services regardless of their functionality Hence we only distinguish the technicaland legal requirements and do not further partition the requirements with respect to privacy security and trustrequirements as it was planned in the earlier iterations of D12

As we complete the final iteration of Deliverable 12 we conclude that we have consolidated the viewpointsinto a monolithic set of technical requirements whose interaction with both the legal requirements and thearchitecture are analyzed and validated We believe D12 will continue to provide a stable basis upon which tocomplete the activities of the TAS3 project

Version 20

Bibliography[1] A Aurum and C Wohlin Requirements interdependencies State of the art and future challenges In

Engineering and Managing Software Requirements 2006

[2] E Barka and R Sandhu Framework for role-based delegation models In The 16th Annual ComputerSecurity Applications Conference (ACSACrsquo00) Los Alamitos CA USA pages 168 ndash177 2000

[3] O Canovas and A F Gomez Delegation in distributed systems Challenges and open issues In The14th International Workshop on Database and Expert Systems Applications (DEXArsquo03) Prague CzechRepublic pages 499ndash503 2003

[4] P Carlshamre K Sandahl M Lindvall B Regnell and J N Dag An industrial survey of requirementsinterdependencies in software product release plannin In RE rsquo01 Proceedings of the Fifth IEEE Inter-national Symposium on Requirements Engineering pages 84 ndash 91 Washington DC USA 2001 IEEEComputer Society

[5] L Casalo J Cisneros C Flavian and M Guinalıu Determinants of success in open source determinantsof success in open source software networks Industrial Management and Data Systems 2009

[6] L Casalo C Flavian and M Guinalıu The role of perceived usability reputation satisfaction and con-sumer familiarity on the website loyalty formation process Computers in Human Behavior 24(2)324ndash3452008

[7] D Chadwick Delegation issuing service for x509 In The 4th Annual Research and Development PKIWorkshop Gaithersburg MD USA 2005

[8] D Chen and G Doumeingts European initiatives to develop interoperability of enterprise european ini-tiatives to develop interoperability of enterprise applicationsmdashbasic concepts framework and roadmapAnnual Reviews in Control 27153 ndash 162 2003

[9] S Chou E J Lu and Y-H Chen x-rdr a role-based delegation processor for web-based informationsystems ACM SIGOPS Operating Systems Review 39(1)4ndash21 2005

[10] A Cockburn Goals and use cases Journal of Object Oriented Programming 1997

[11] B Crispo and G Ruffo Reasoning about accountability with delegation In 3rd International Conferenceon Information and Communication Security 2001

[12] E Cristobal C Flavian and M Guinalıu Perceived e-service quality (pesq) measurement validation per-ceived e-service quality (pesq) measurement validation and effects on consumer satisfaction and websiteloyalty Managing Service Quality 17(3)317ndash340 2007

[13] M R Czenko and S Etalle Core tulip - logic programming for trust management In V Dahl and I Niemelaeditors Proc ICLP 2007 Porto Portugal volume 4670 of LNCS pages 380ndash394 Berlin October 2007Springer Verlag

[14] C Flavian M M Guinalıu and R Gurrea The role played by perceived usability satisfaction and consumertrust on website loyalty Information and Management 43(1)1ndash14 2006

[15] S Gurses G Montagnon M Seguran and N Zannone Requirements engineering within a security-oriented project lessons learned requirements engineering within a security-oriented project lessonslearned In Requirements Engineering 2010 (submitted)

[16] P Herings G v d Laan and D Talman Measuring the power of nodes in digraphs Technical reportTinbergen Institute 2001

[17] S D Kamvar M T Schlosser and H Garcia-Molina The eigentrust algorithm for reputation managementin p2p networks in proc In 12th International Conference on World Wide Web pages 640 ndash 651 2003

Version 20

[18] S Kellomaki Deliverable 21 Architecture Technical report TAS3 2009

[19] J M Kleinberg Authoritative sources in a hyperlinked environment Journal of the ACM 46(5)604 ndash 6321999

[20] N Lin Foundations of Social Research New York McGraw-Hill 1976

[21] S Marczak D Damian U Stege and A Schroter Information brokers in requirement-dependency socialnetworks In 16th IEEE International Requirements Engineering Conference 2008

[22] G Montagnon Deliverable 14 Design requirements Technical report TAS3 2009

[23] J Mulle Deliverable 31 Design of a semantic underpinned secure and adaptable process managementplatform Technical report TAS3 2009

[24] L Page S Brin R Motwani and T Winograd The pagerank citation ranking Bringing order to the webTechnical report Stanford University 1998

[25] J-C Pazzaglia Deliverable 11 State of the art Technical report TAS3 2008

[26] J Robertson and S Robertson Volere requirements specification template Edition 14 Atlantic SystemsGuild 2009

[27] A D Toro B B Jimenez A R Cortes and M T Bonilla A requirements elicitation approach based intemplates and patterns In Workshop Engineering Requirements (WERrsquo99) 1999

[28] T Valente and R Foreman Integration and radiality Measuring the extent of an individualıs connectednessand reachability in a network Social Networks 20(89)105 1998

[29] A Yamamoto D Asahara T Itao S Tanaka and T Suda Distributed pagerank A distributed reputationmodel for open peer-to-peer networks In SAINT-W ı04 (SAINT ı04 Workshops) Washington DC USA2004

Version 20

Part II

Deliverable 12 SupportingDocuments

Version 20

A Requirements Assessment TemplatesA1 Template 1 for Gap Analysis and Requirements Elaboration

Instruction 1 Describe the objectives of the workpackage (5-10 lines) Those objectives should be con-sistent with the ones in the Description of Work and the Workpackage Deliverables Further they should takethe two scenarios above as a point of reference If it applies you may specify which part of the scenarios orwhich properties of the scenarios the activities in your workpackage support

Instruction 2 Describe solved and unsolved problems in the field of trust and security in service-orientedopen and distributed environments in the context of the Workpackage Include literature about existing researchandor software addressing the objectives described in Instruction 1 and discuss why such researchimplemen-tations are sufficientnot sufficient to address those objectives (2 paragraphs) If you need to refer to detailsplease feel free to refer to other deliverables

Instruction 3 Write down the technical legal and application requirements that apply to the activitiesin your work package You may use the requirements that you submitted to the prior Deliverable 12 Allrequirements should be formulated in full sentences using MUSTSHALL for requirements that are mandatoryand SHOULD for those that are optional but nice to have Requirements should define problems that need tobe solved and not solutions that need to be adopted (eg rdquoWorkpackage shall implement separation of dutiesrdquois not a requirement) For each requirement include

bull a short justification for the requirement You are encouraged to include reference to the applicationscenarios above

bull how it interacts with other requirements in your work package You can distinguish between the following

ndash A depends on B requirement A requires requirement B B is a condition for A

ndash A supports B requirement A is needed to fulfill requirement B A is a condition for B

ndash A implements B requirement A is a specialization of requirement B

ndash A abstracts B requirement A is a generalization of requirement B

ndash A is in conflict with B requirement A and requirement B are logically inconsistent or the implemen-tation of both requirements is not feasible

You should include interactions among your workpackage requirements as well as the interaction of your re-quirements with the design requirements defined in Deliverable 14 [22]The numbering of the requirements are as follows

DeliverableNumber-WorkpackageNumberRequirementNumber

Instruction 4 List available solutions which you can use of to fulfill the requirements of your work packageYou may userefer to the list of software you submitted to the prior D12 or to the State of the Art in Deliverable11 Provide information using the following template

Name of Software PackageLinkAccess Open SourceOpen Standard or proprietary any limitationsFunctionalityLimitations with respect to TAS3Related Requirements include which requirements can be fulfilled using this softwareFor the software or application of your choice add to the templateJustification for selectionand please include why you have selected this one over the others

Version 20

Instruction 5 Provide a list of the requirements distinguishing between

bull requirements that cannot be fulfilled because necessary research or implementations are missing Ex-plain shortly how you will be attending to those requirements within the project If possible explain howyou plan to validate that those requirements are fulfilled

bull requirements that will not be fulfilled because they are beyond the scope of TAS3 please give a convinc-ing justification if this is the case

A2 Template 2 for Inter-WP interactions

Please fill in the following table for each of your requirements that have interactions with the requirements ofother WPs Use the list of requirements in Appendix C We have provided you with a controlled vocabulary toname the interactions These are defined as follows

bull A supports B requirement A is needed to fulfill requirement B

bull A is in conflict with B requirement A and requirement B are logically inconsistent or the implementationof both requirements is not feasible

bull A is similar to B A is similar to or overlapping with B

We have also created a row for any notes you want to make Please make use of this if you want to explainan interaction in more detail or if somehow you are not sure about the interaction or you want us to includesomething about the interaction in the deliverable And last we have a field for who will fulfill the requirement Ifit is not only your teamwork package but also requires activities by other work packages please list those workpackages here

At the end of the interaction analysis process you may feel the need to document some new requirementsplease feel encouraged to do so If your interaction analysis generates new requirements these should beformatted like all the other requirements with a requirement ID number the requirement itself justification andinteraction

We are aware that this is a repetitiveiterative work We expect it to nevertheless be useful and to makevisible the interactions between the work packages Especially we expect it to be helpful in mapping out thoseinteractions between the technical demonstrator and legal work packages which all have different emphasesand strong interactions We thank you for your collaboration and look forward to receiving your interaction tablesPlease feel free to contact us if you think anything is unclear or if you have any questions or comments

A3 Template 3 for Requirements Updates

Step 1 New edited or deleted requirements and consolidation of similar requirements

Step 1A Instructions The following are the requirements of your WP listed in D12 Please review thislist You may decide to edit add or delete some of these requirements on this page by clicking the rdquoEdit thispagerdquo button at the bottom of this page Here are the instructions on how to do each of these actions

bull add new requirements if you have elaborated any new requirements in the last months relevant to D12(gap analysis and research requirements) please add these to the list below For any new requirementplease keep the requirements template from D12 shown below All requirements should be formulated infull sentences using MUSTSHALL for requirements that are mandatory and SHOULD for those that areoptional but nice to have Requirements should define problems that need to be solved and not solutionsthat need to be adopted For the interactions please pay attention to the definition of the controlledvocabulary below and only use these relationships to define interactions

Version 20

ReqID D12-17 (NEW)Requirement The different policies should be machine readableJustification This requirement refined D12-16Interaction implements D12-16

Here is the controlled vocabulary for interactions

Last please do not forget to add the (NEW) tag next to the ReqID to indicate that this is a new require-ment

bull edit an existing requirement if you need to change the formulation of any of your requirements pleasedo so and indicate that you have done so next to the ReqID ie D12-61 (Edited)

ReqID D12-17 (EDITED)Requirement The different policies should be machine readableJustification The requirement D12-17 contained two different requirements

these are now split in D12-17 and D12-18

bull delete a requirement if you need to delete a requirement please indicate that this needs to be so nextto the ReqID ie D12-61 (Delete) Please also add a justification for the deletion Example

ReqID D12-17 (DELETED)Requirement The different policies should be machine readableJustification The requirement D12-17 contained two different requirements

Step1B In the first iteration of D12 each partner indicated interactions with the requirements of other WPsOne of the interaction types was of similarity suggesting that two requirements are similar or overlappingPlease find below the requirements that other WPs have indicated are similar to yours You can either confirmthe similarity and the two requirements will be merged If you disagree with the similarity relationship then pleaseconsider contacting those WPs to better distinguish their difference Otherwise please either state why the tworequirements must be included although they are similar change the wording so that the distinction is clearor suggest a new relationship between the two requirements (supports depends implements or abstracts asdefined above)

For example ldquoD12-312 is similar to D12-47 but this is justifiable because D12-312 articulates the specificsof this requirement which is crucial to business processesrdquo orldquothe label between D12-312 and D12-47 shouldbe changed to a ldquodependsrdquo relationship as this better reflects the relationship between the two requirementsrdquo

For the updates please use the given notation language (dot) which looks like thisldquoRequirement 1rdquorarr ldquoRequirement 2rdquo [label = ldquoType of interactionrdquo]where Type of Interaction is an element of the controlled vocabulary which is made up of the following set

bull S Supports means requirement A is needed to fulfill requirement B A is a condition for B

bull D Depends means requirement A requires requirement B B is a condition for A

bull A Abstracts means requirement A is a generalization of requirement B

bull I Implements means requirement A is a specialization of requirement B

bull Sim Similar means A is similar to or overlapping with B

bull C Conflicts means requirement A and requirement B are logically inconsistent or the implementation ofboth requirements is not feasible

Version 20

Requirements are written in the format of the deliverable D12-WPReqYou can access the graph in the dot format when you edit this page and add changes to relationship labels

directlyDOCUMENTATION AND JUSTIFICATION OF CHANGESPlease add your comments here Indicate for each requirement with similarities if you agree with the simil-

iarity (in which case the two requirements will be merged) or if you decided to make changes to the wording orlabel of your requirement You may also justify why the similarity relationship is not correct Any changes willalso be confirmed with the relevant WPs

Version 20

B Updates to Requirements of TAS3

This section presents the updates to the requirements elaborated by the partners as part of the gap analysisThe requirements are grouped in three new requirements changed requirements and deleted requirementsEach requirement has a requirement ID a justification for the introduction editing or deletion of the requirement

B1 New Requirements of TAS3

These are the new requirements captured in TAS3

ReqID D12-314Requirement Business processes MUST be executable in the Trust Network It is

fundamental for all requirements in respect to enforcing security andprivacy in business processes

Justification It is fundamental for all requirements in respect to enforcing securityand privacy in business processesThe requirement had previouslybeen forgotten

ReqID D12-512Requirement The trust management system SHALL support ranking entities ac-

cording to trustworthiness scoreJustification Ranking providers according to trustworthiness will be convenient

for a user choosing between suitable providers (eg as part of theservice discovery and selection procedure)

ReqID D12-728Requirement The system must be able to send users summary audits of accesses

and attempted accesses to their personal dataJustification Gives the user visibility that hisher privacy policy is being enforced

correctlyReqID D12-729Requirement Users externally assigned roles and attributes should be mapped into

internal authorisation attributesJustification Separates authorization attributes from externally assigned at-

tributes and allows external attribute authorities to be replaced Italso separates workflow authorization attributes from organizationalroles

ReqID D12-87Requirement An end user SHALL be able to be in control of her data using a web

based dashboard applicationJustificationReqID D12-88Requirement All TAS3 core components SHALL be able to log errors and process

informations in an audit serviceJustificationReqID D12-89Requirement User SHOULD be able to negotiate the meaning of the vocabulary

collaborativelyJustificationReqID D12-917Requirement The system MUST take care of policy combinations and have a

mechanism to resolve different policies interacting on data at thesame time

Justification There will be policy combinations so the system must be able tohandle those

ReqID D12-918

Version 20

Requirement There SHOULD be provision for journaling of data showing whatdata has been changed and who has changed what

Justification Track back of data is necessary in case of doubt or indistinctnessReqID D12-919Requirement The system SHOULD provide means to guarantee data integrity and

authenticityJustification Data should not be changed by the Service Provider and it should be

possible to see who the original author isReqID D12-920Requirement There MUST be a provision for confidentiality in data transmissionJustificationReqID D12-921Requirement There MUST be provision for different levels of authentication au-

thorisation and trust and to encompass existing mandatory securitymechanisms

JustificationReqID D12-922Requirement There MUST be a mechanism to establish trust between service

providersJustificationReqID D12-923Requirement Processes MUST only be able to access specific data they need in

order to execute successfullyJustification The requirement D12-91 contained two different requirements

these are now split in D12-91 and D12-923ReqID D12-924Requirement Service providers MUST act on dynamically set privacy policies with

immediate effectJustification The requirement D12-99 contained two different requirements

these are now split in D12-99 and D12-924ReqID D12-925Requirement Users MUST be informed about the consequences of their choosen

or pre-set policies they must clearly understand the implications ofthis policy choice

Justification The requirement D12-96 contained two different requirementsthese are now split in D12-96 and D12-925

ReqID D12-926Requirement All users MUST be securely authorised before any access to data is

allowedJustification The requirement is split into D12-94 and D12-926ReqID D12-927Requirement (Final)TAS3 demonstrators MUST be subject to formal usability test-

ingJustification Usability requirements were moved from WP10 and applied to

demonstratorsReqID D12-928Requirement Demonstrator usability testing MUST evaluate end user perceptions

of trust in the TAS3 systemJustification Usability requirements were moved from WP10 and applied to

demonstratorsReqID D12-929Requirement Demonstrator usability testing MUST capture and record both user

expectations and perceptions of usability of the TAS3 systemJustification Usability requirements were moved from WP10 and applied to

demonstrators

Version 20

ReqID D12-1021Requirement The Audit and Monitoring domain of the TAS3 SHOULD notify autho-

rization failures to the Authorization Infrastructure of TAS3Justification This requirement is a refinement of D12-102 Interaction D12-

1021ReqID D12-1022Requirement The Audit and Monitoring domain of the TAS3 SHOULD notify autho-

rization failures to the Trust Reputation Infrastructure of TAS3Justification Justification This requirement is a refinement of D12-102ReqID D12-1081Requirement Services that are to participate in a TAS3 choreography MUST be

accompanied with models describing their public interfaceJustification This requirement is a refinement of D12-108ReqID D12-1082Requirement Services that are to participate in a TAS3 choreography MUST be

accompanied with models describing their access policyJustification This requirement is a refinement of D12-108ReqID D12-685Requirement Availability the TAS3 technical authorization infrastructure MUST

ensure that legitimate persons shall have ready to access personaldata particularly in emergency situations (eg when it is necessaryto safeguard the vital interests of the data subject)

JustificationReqID D12-6851Requirement Where a user decides to override the ordinary authorization pro-

cess under the pretext of an emergency appropriate notificationsand follow-up procedures to deter abuse must be executed

JustificationReqID D12-686Requirement Data minimization appropriate measures MUST be in place to avoid

unnecessary duplication of personal data in multiple repositoriesJustificationReqID D12-687Requirement Use of feedback information Users SHALL have the ability to spec-

ify how the feedback they provide with regards to service providersand service experiences may be used (eg only for the purpose ofcalculating reputations)

JustificationReqID D12-6871Requirement The operator of the Trust Reputation server MUST be bound to only

process user feedback information in accordance with the users poli-cies

JustificationReqID D12-688Requirement Outsourcingdelegation of responsibilities of TAS3 participants

TAS3 participants MUST be bound to outsource or delegate onlythose tasks for which outsourcing or delegation is permitted

JustificationReqID D12-6881Requirement Where a TAS3 participant decides to outsourcedelegate a task

which involves the processing of personal data this entity mustchoose a processor providing sufficient guarantees in terms of tech-nical security measures and organizational measures

JustificationReqID D12-6882

Version 20

Requirement Any TAS3 participant outsourcingdelegating a task which involvesthe processing of personal data must ensure that the processingis governed by a contract or legal act binding the processor to thecontroller which stipulates (1) that the processor shall act only oninstructions from the controller (2) that the processor is subjectto the confidentiality and security obligations set forth by Directive9546EC

Justification

B2 Edited Requirements of TAS3

These are the requirements which have been edited to better articulate the needs of TAS3 WPs

ReqID D12-34Requirement Users MUST have an identifier that stays the same throughout the

execution of a business process instanceJustification This clarifies what specific properties an identity management must

fulfill in order to be used with business processesReqID D12-37Requirement Participants in business processes MUST be able to delegate their

responsibilities and permissions in a controlled manner [added thispart] on a per process-instance level

Justification Distinguish it from the general D12-71 and point out the WP3 spe-cific details

ReqID D12-39Requirement Business processes SHOULD be able to recover from error situa-

tionsJustification This is a feature which would be nice to have in particular casesReqID D12-312Requirement Users SHOULD be able to annotate business processes with con-

cepts eg from the TAS3 ontology to achieve semantic interoperabil-ity to comply to a common security and privacy vocabulary

Justification Clarify the distinction between D12-223 and this requirement focusmust be on security and privacy

ReqID D12-510Requirement A user SHALL be able to prove her identity when providing trust feed-

backJustification The old formulation (The TAS3 architecture SHALL support user

identification) too generalReqID D12-91Requirement Processes MUST have secure access to data drawn from a variety

of existing sourcesJustification The requirement D12-91 contained two different requirements

these are now split in D12-91 and D12-923ReqID D12-92Requirement Users MUST be able to set view control and change policies for their

data (or data objects) at a variety of levels down to the lowest (field)level from accepting and assembling clearly-formulated pre-set poli-cies to adding fine-grained policies to specific sets of data (or dataobjects) they must clearly understand the implications of this policychoice Any inherent contradictions or inconsistencies SHOULD bepointed out to users before the policy is accepted

Justification ExtensionReqID D12-93

Version 20

Requirement Users MUST have easy and easily-understood access to the sys-tem without the need for overly-complex authentication and autho-rization processes preferably via SSO and using a familiair interface

Justification RefinementReqID D12-94Requirement All users MUST be securely authenticated before any access to data

is allowedJustification The requirement is split into D12-94 and D12-9-26ReqID D12-95Requirement There MUST be a secure and reliable audit trail showing who ac-

cessed user PII when and for what purpose and whether anychanges were made and this audit trail must in turn be secureand only accessible by the user authorised individuals or serviceproviders

Justification RefinementReqID D12-96Requirement Users MUST be able to set specific policies for all possible data-

requesters from highest level (countryinternational organisations)down to the lowest level (named actor) including accepting clearly-formulated pre-set policies for common data-requesters

Justification The requirement is split into D12-96 and D12-9-25ReqID D12-98Requirement Users MUST be able to see who (named actor) has requested ac-

cess to which of their PII data and whether or not access wasgranted

Justification RefinementReqID D12-99Requirement Users MUST be able to change the policies attached to their PII data

at any timeJustification The requirement is split into D12-99 and D12-9-24 Interaction

Similar to D12-77ReqID D12-66Requirement Binding Effect of technical processes and policies All TAS3 partici-

pants and users MUST agree to be bound by the technical processeswithin the TAS3 network including the obligations resulting from thetransactions they engage in or choices they exercise through theTAS3 architecture

Justification integration Req 65 and 66ReqID D12-661Requirement All TAS3 participants and users MUST agree to accept the contents

of TAS3 logs as evidence of their actions within the TAS3 network (tothe extent the relevant logging mechanisms are working properly andtheir properties have been appropriately disclosed and consentedto)

JustificationReqID D12-665Requirement Policies MUST be drafted and communicated in a way that is appro-

priately tailored to and accessible by its intended audience so asto enable all relevant parties to understand their scope of applicationand which resources (data services etc) are governed by whichpolicies

Justification Req 665 and 666ReqID D12-67

Version 20

Requirement Implementation of Required Policies Organizational participants inthe TAS3 network MUST implement TAS3 defined or compatible poli-cies specified in the contractual framework (eg internal privacy andsecurity policies) or as approved during the intake process See alsoReq 669

Justification reference to Req 669 addedReqID D12-610Requirement Collection use and subsequent use of personal data MUST be with

the informed consent of the data subject EXCEPT where mandatedby law or through an exception recognized in law

Justification removed finality component from 610 already dealt with in 615 etseq

ReqID D12-616Requirement Consent Capture for New or Changed Use If an entity wishes to

process personal data in a manner which cannot objectively be con-sidered as compatible with the originally specified purpose(s) a newinformed consent MUST obtained from the data subject prior to thisnew or changed use unless this processing is explicitly required orpermitted by law

Justification integration 612 and 616ReqID D12-6182Requirement The data recipient MUST be legally bound to restrict itself to autho-

rized usage and to execute the obligations specified in these datahandling policies (see also Reqs 65-66)

Justification typo specified was mentioned twiceReqID D12-623Requirement Response to attribute requests and granular access control Tech-

nical policy enforcement mechanisms MUST have the ability to re-spond to data requests with only that information that the requestingentity needs to receive in order to achieve the purposes of the pro-cessing See also Req 637

Justification modified is authorized -iquest needs + added to receive in order toachieve the purposes of the processing

ReqID D12-6241Requirement Mechanisms SHALL be in place to enable the user to choose which

identity providers andor attribute authorities shall be used for a par-ticular service subject to applicable policy (eg minimum level ofassurance prerequisite attributes for authorization decision etc)

JustificationReqID D12-6282Requirement In the event of indirect collection the accuracy of the data SHOULD

be verified with the data subject where this is both possible and ap-propriate

Justification removed priorReqID D12-6371Requirement A list and directory of resources (eg applications data) and cate-

gories of potential usersdata recipients MUST be madeJustification inserted categories ofReqID D12-639Requirement Avoid unnecessary linkability TAS3 SHALL support advanced

pseudonym management to limit the level of linkability or correlationamong personal data to that which is necessary

Justification appropriate -iquest to that which is necessaryReqID D12-657

Version 20

Requirement A (back-office) procedure SHOULD be in place to adequately dealwith the situation whereby a TAS3 actor receives a data subject re-quest which is not competent to decide itself

Justification

B3 Deleted Requirements of TAS3

This is the list of requirements that have been removed from TAS3 due to overlaps re-focusing of scope orchange of responsible workpackages

ReqID D12-97Requirement Users MUST be able to check (read) their personal data stored in all

possible data stores connected to the TAS3 infrastructure and con-test any that they feel is inaccurate

Justification This is not part of TAS3 its more about the contractual arrangementbetween the user and the service provider or part of the national le-gal framework The data stores are not part of the TAS3 architecture

ReqID D12-911Requirement Interoperability between different systems MUST be established to

exchange and share data This includes interoperability betweencredential providers

Justification D12-223 says that the TAS3 architecture must facilitate interoper-ability

ReqID D12-913Requirement Actors (data-requesters service providers) MUST be able to connect

to the TAS3 infrastructure in a secure way using varying levels ofauthentication and trust

Justification Replaced by D12-921ReqID D12-915Requirement TAS3 specific processes SHOULD not adversely affect performance

or add complications to existing processes from the users viewpointJustification This is a requirement for an operational systemReqID D12-104Requirement Demonstrators SHALL provide good levels of end-user perceived

trustJustification This requirement was introduced by UNIZAR After the revision of

the DOW UNIZAR already completed their effort in WP10 Probablysomeother WPs is currently dealing with this aspect

ReqID D12-105Requirement Demonstrators SHALL provide good levels of end-user perceived us-

abilityJustification This requirement was introduced by UNIZAR After the revision of

ReqID D12-107Requirement Demonstrators SHALL provide good levels of accessibility

Version 20

Justification This requirement was introduced by UNIZAR After the revision ofthe DOW UNIZAR already completed their effort in WP10 Probablysomeother WPs is currently dealing with this aspect

ReqID D12-65Requirement Agreement to be bound All parties MUST agree to be bound to

the obligations they take on both by becoming and being part of theTAS3 network as well as those which are the result of transactionsor choices they exercise through the TAS3 Architecture

Justification integration Req 65 and 66ReqID D12-666Requirement The policies SHALL be drafted in a way which enables all parties

to understand their scope of application and which resources (dataservices etc) are governed by which policies

Justification integration Req 665 and 666ReqID D12-612Requirement Consent Capture for New or Changed Use If the use of information

changes or if there is a new use of information there MUST be anew informed consent obtained prior to the new or changed use ofinformation (see also Req 616)

Justification integration 612 and 616ReqID D12-6378Requirement Adequate measures and procedures MUST be in place to support

enforcement of authorization policies at both central and local levelsJustification depends on model of implementation

Version 20

C Requirements of TAS3

This section presents the requirements elaborated by the partners as part of the gap analysis The re-quirements are grouped with respect to the work packages that elaborated them Meaning the requirementis important for the partners in that given work package but they may depend on other work packages forthe fulfillment of the requirements Each requirement has a requirement ID a justification for the introduction ofthe requirement and an analysis of the interactions of the requirements with other requirements in that given WP

C1 General Requirements of TAS3

These are requirements that follow from the objectives of TAS3 and have been provided by WP2

ReqID D12-21Requirement TAS3 Architecture MUST be feasible to implementReqID D12-22Requirement TAS3 Architecture MUST be feasible to deployReqID D12-23Requirement TAS3 Architecture MUST support plurality of service business mod-

elsReqID D12-24Requirement TAS3 Architecture MUST support multiple software suppliersReqID D12-25Requirement TAS3 Architecture MUST be platform independentReqID D12-26Requirement TAS3 Architecture MUST be programming language agnosticReqID D12-27Requirement TAS3 Architecture MUST be fail safe ie failure should not lead to

security breachReqID D12-28Requirement TAS3 Architecture MUST be availableReqID D12-29Requirement Implementation MUST correctly implement TAS3 ArchitectureReqID D12-210Requirement TAS3 MUST appear to the users to work correctlyReqID D12-211Requirement The functionality of TAS3 must be transparent to the users (user can

see what is going on)ReqID D12-212Requirement TAS3 MUST be comprehensible to the user The user MUST be able

ReqID D12-213Requirement TAS3 MUST be easy to useReqID D12-214Requirement TAS3 MUST appear to the user to be privacy protectiveReqID D12-215Requirement TAS3 MUST make it possible to hold people and companies account-

able for the activities with respect to personal data

Version 20

C2 Requirements of WP2

of the architectureJustificationInteractionReqID D12-217Requirement TAS3 MUST provide an untamperable audit trailJustificationInteractionReqID D12-218Requirement Authentication in TAS3 MUST be credibleJustificationInteractionReqID D12-219Requirement Authorization in TAS3 MUST be credibleJustificationInteractionReqID D12-220Requirement TAS3 MUST guarantee only authorized disclosures and actionsJustificationInteractionReqID D12-221Requirement TAS3 MUST implement data protection legislation in technologyJustificationInteractionReqID D12-222Requirement TAS3 MUST permit access to the audits for legitimate authorities if

this is legally necessaryJustificationInteractionReqID D12-223Requirement Semantic interoperability should be achieved across web services

and business processesJustification Web services and business processes need to comply to specific se-

curity and privacy protocol and provide a measure of trustworthinessto allow communication across the TAS3 architecture

Interaction D12-R312 D12-R314

ReqID D12-31Requirement Process designers SHOULD be given tools to define (graphical)

models of their business processes including the interactions of theprocess with external components ie web services and human ac-tivities (web interfaces) and other business processes

Justification It is not feasible to define a business process model without tool sup-port as processes can get quite complex This especially holds asseveral aspects have to be included into the model such as inter-faces services trust and security

Interaction Abstracts D12-36ReqID D12-32

Version 20

Requirement Service providers MUST be able to automatically translate theirsecurity-aware process models into an executable form and into se-curity parameters configuring some parts of the trust and securityinfrastructure

Justification Having (graphical) process models just as documentation that thenmust be implemented (again) manually is insufficient as there is noguarantee that the model and especially the security settings is im-plemented faithfully

Interaction Depends on D12-31ReqID D12-33Requirement Users MUST have an interface where they can see their present

tasks in business processes and the present status of the processesthey are currently involved

Justification Business processes involve humans like a job seeker who must havea user interface to interact with the process eg to provide hisherportfolio

InteractionReqID D12-34Requirement Users MUST have an identity in the business process that is compli-

ant with their identity at other service providersJustification Business processes process inter alia PII Such PII (like a diploma)

is retrieved from other service providers (like an authentic datasource) and possibly sent for processing to other providers (eg tocheck and amend it)

Interaction Support D12-33 Abstracts D14-31ReqID D12-35Requirement Process designers MUST be able to specify the assignment of tasks

to actors in a business process in a sufficiently abstract flexible andsecure way using roles for grouping tasks and responsibilities

Justification Employees and their responsibilities can change often and quicklythus a process model cannot determine the exact individuals respon-sible in advance Thus specifications must allow for flexibility butwithout loss of security In a business process several people coop-erate to achieve a common business goal For example the KenteqAPL process (see D31) detailing the assessor Kenteq in the firstscenario above involves ie coach assessor and quality controllerTheir responsibilities and the activities they have to perform for eachperson category are the same regardless of who actually performsthe function Thus they can best be described using roles

Interaction Abstracts D12-36 Supports D12-39 Abstracts D14-32ReqID D12-36Requirement Business process providers (in general coordinators of a complex

service) MUST be able to control who performs a task by bindingauthorization to perform a task and access necessary resources toroles

Justification Control of who performs a task is critical for achieving the objectiveof a business process and to keep PII secure An example for a task(taken from the Kenteq APL process) is to view the competency pro-file of the candidate (PII) and make an approval decision based onthat Specifying authorisation for each task and each access per-mission is a tedious and error-prone task It is often clear in advancewhat kind of data is involved in the business process (eg the per-sonal competency profile of the candidate) and who must be able toaccess it (eg the coach and the assessor) so authorizations canoften be bound to a role by a manual decision or a defined policy

Version 20

Interaction Implements D12-31 D12-35 Supports D12-39 Abstracts D14-33

ReqID D12-37Requirement Participants in business processes MUST be able to delegate their

responsibilities and permissions in a controlled mannerJustification When participants are unavailable or overloaded with work it must

be possible for the business process to proceed towards its objec-tive but with appropriate control because responsibilities and per-missions are transferred

Interaction Supports D12-36 Similar to D14-34ReqID D12-38Requirement Process designers MUST be able to specify mutual exclusion be-

tween roles in the scope of a processJustification Some responsibilities within a business process are incompatible in

the sense that they may not be performed by the same person oth-erwise security would be compromised This especially concerns sit-uations where the holder of one role supervises the decisions of thatof the other one Eg the assessor approves a profile the candidatehas created with assistance from the coach

Interaction Implements D12-36 Supports D12-39 Similar to D14-35ReqID D12-39Requirement Business processes MUST be able to recover from error situationsJustification It is not always completely foreseeable if resources are accessible

at runtime However a fault might be recoverable eg by repeatingthe request after initiating a break-the-glass procedure requestingnecessary permissions to be granted or choosing another source Arecoverable fault should not cause termination of the business pro-cess

Interaction Similar to D14-310ReqID D12-310Requirement Permissions SHOULD only be valid when neededJustification Roles imply access permissions to resources connected with the

business process However they are not necessarily needed for thewhole duration of the process To prevent abuse they should not beusable when not needed

Interaction Implements D12-36 D14-33ReqID D12-311Requirement Users MUST be able to specify on which of their PII the process

should have access and service providers MUST be able to discoverfor a particular piece of PII which user settings apply and whether thePII is particularly sensitive

Justification Each business process has distinct needs about the data to pro-cess The user must be able to see these requirements in advancetogether with a privacy policy Further in the employability domainportfolios can contain sensitive data for example medical data orcriminal records For instance the personal competency profile of anAPL candidate might contain a medical report about health-relatedrestrictions of the candidate Kenteq must be able to detect this in or-der to act appropriately eg by assing specially qualified employeesto deal with the case

Interaction Supports D12-39 Abstracts D14-36 Depends on D14-39ReqID D12-312Requirement Business processes MUST be able to receive sufficient (semantically

interoperable) information about services also business processesavailable from other service providers Especially they MUST beable to inspect the privacy policy

Version 20

Justification Service providers will outsource parts of their business process toother service providers To be able to do so they must have sufficientinformation about the available processes (interfaces assumptionsie pre- and postconditions and effects interaction behaviour non-functional properties)

Interaction Implements Depends on D12-311ReqID D12-313Requirement Business processes SHALL adapt the specified flow to the specific

context of the running process (instance) by replacing a subprocessa used service data or even change the defined flow

Justification Process flows are not always modelled in a fixed manner sometimesit is not possible to foresee all possible alternative flows that mayoccur Eg depending on the candidate the process to perform theassessment or to choose an adequate coach may differ from thepredefined way in the modelled business process Another exampleis that the change of data that will result from calling a subprocessor web service must be handled by adapting the process in that partthat processes that data In these cases an adaptation of the processduring it is running is needed

Interaction Depends on D12-312ReqID D12-314Requirement Choosing an adequate service provider privacy policies for pro-

cesses MUST be available and they must be semantically interop-erable otherwise automatic comparison is not possible at all andmanual comparison is more difficult than necessary as well

Justification Users expect to know as early as possible what PII they need to pro-vide so that a particular business process can complete successfullyor the other way round if the process can complete successfully withthe PII they are willing to contribute

Interaction Supports D12-311ReqID D12-315Requirement Adaption of a process must result in a process with guaranteeing the

same quality level of securityJustification The running process follows an agreement of the process partici-

pants eg the candidate and the assessor which security policyhas to be observed The change of the process must result in aprocess which at least allows following the same security policy

Interaction Implements D12-313 Depends on D12-312

ReqID D12-41Requirement TAS3 MUST be able to enforce user-centric policies on information

gathered from data subjects and on aggregated information sets

Version 20

Justification Information on users and data subjects consists of multiple sets ofelectronic personal identifying information that are stored at authori-tative repositories to avoid multiple possibly conflicting copies of atleast some information Each set is of varying size and complexityand is held in different digital formats Different subsets of this infor-mation have different sensitivity levels Some of these subsets maybe considered publicly accessible information (eg postal addresstelephone number) some of it the user may be willing to share witha wide range of people (eg degree classification or other awards)other of it will be highly confidential with the users only wishing toshare it with close associates (eg career plans) whilst yet otherof it may have strict legal restrictions on who may view the infor-mation and under what conditions (eg sexual preference) Oneset of such information may refer to another set of information andusers (human and other) need to be able to determine whether theirdatainformation has been processed by actors in a manner that iscompatible with the policies they agreed on while the datainforma-tion was collected This requirement guarantees compliance withdata protection legislation such that personal information is handledappropriately by the recipients subjects and holders of the personalinformation

Interaction Depends on D12-44 D12-48 D12-49ReqID D12-42Requirement Distinct transactions or executions of a business process that takes

place in the TAS3 environment MUST be indistinguishable from oneanother

Justification An outside observer should not be able to determine whether twodistinct runs of a transaction or business process relate to the sameentity Note that subsets of personally identifying information arelikely to be identified in different repositories with different uniquebut unrelated identifiers If such information includes eg nationalidentification numbers the transactions dealing with this informationmay be indistinguishable but the information itself not

Interaction Supports D12-44hline ReqID D12-43Requirement It MUST be possible to demonstrate the complex security and trust

features of the TAS3 functionality and concepts in a comprehensibleway for lay users

Justification Because the concepts the project is about are rather complex and avisual tool is the bestsimplest way to convey the message to the layuser

Interaction Depends on D12-41 D12-42 D12-44 D12-47 D12-48 D12-49 Supports D12-45

hline ReqID D12-44Requirement TAS3 service providers MUST be able to prove that they processed

the information and services in accordance to the required policiesThe proof MUST be usable in court

Justification This is necessary to comply with basic data protection requirementswith respect to oversight and with the End-to-End trustworthiness ofthe TAS3 system Any service provider or consumer must be able toprove who processed data for what purpose etc This is especiallynecessary for gateways between TAS3 service providers and legacyrepositories when dealing with information held in legacy databases

Interaction Depends on D12-42 D12-45 D12-46 D12-47 D12-48 D12-49

hline ReqID D12-45

Version 20

Requirement Each TAS3 actor (ie service provider or service consumer) MUSTprocess the information in compliance with the appropriate policies

Justification This is necessary to implement the proportionality and finality prin-ciples of data protection regulation The data subject serviceproviders and service consumers may extend and narrow down in-formation and policies while exchanging information during the exe-cution of a business process

hline ReqID D12-46Requirement In exceptional situations an identified TAS3 actor needs to be

granted access to information to which access would be denied un-der normal circumstances Such functionality MUST be offered byTAS3

Justification This is due to liability issues when dealing with life-and-death mat-ters one would not like to be held liable if some important informa-tion was not available or accessible because of technical matters Ifdata is needed to deal with life threatening issues it should be madeavailable to (properly identifiable) actors

Interaction Depends on D12-41ReqID D12-47Requirement TAS3 service consumers MUST be able to discover service providers

that commit to meeting their requirements and policiesJustification Service consumers are not able to know beforehand which service

providers exist and whether the existing ones can meet the con-sumers expectations with respect to the policies and functionalitythey can provide

Interaction Depends on D12-48 D12-49 Supports D12-41ReqID D12-48Requirement TAS3 discovery service and policy management system MUST be

user friendly and easy to configure and useJustification The TAS3 system needs to be usable by non-expert usersInteraction Depends on D12-49 Supports D12-43ReqID D12-49Requirement TAS3 discovery service MUST take into account the trust and repu-

tation score of both service consumers and providersJustification Because the TAS3 system needs to select service providers that

comply with the relevant policies These policies may specify cer-tain trust and reputation requirements

Interaction Supports D12-41

ReqID D12-51Requirement The trust management system SHALL answer trust policy evaluation

requests which can use different sources of trustJustification Usersrsquo trust (see eg step 5 of the APL scenario) depends on differ-

ent sources such as credentials reputations or economical informa-tion The trust management system must support combinations ofsuch sources of trust to capture the users trust requirements

Interaction Depends on D12-52 which provides the policy language to be usedAbstracts D14-52 D14-54(b) D14-57 D14-58 D14-59Implements D14-51

ReqID D12-52

Version 20

Requirement The trust management system SHALL define a combined trust pol-icy language that allows user to formulate trust policies based oncredentials reputations and economical information

Justification The reason why an entity trusts another entity can be the role an en-tity plays eg a certified doctor andor the past performance of theentity in a given task or with respect to some economical parame-ters The trust management system needs to support these differentsources of trust in its policies

Interaction Supports D12-51 D14-51(ab)ReqID D12-53Requirement The trust management system SHALL provide a reputation based

trust management serviceJustification To evaluate the trustworthiness of entities of services based on rep-

utations which are built from (user) feedbackInteraction Supports D12-51 D14-54 D14-51(ab)

Depends on D12-52ReqID D12-54Requirement The trust management system SHALL support the gathering of rep-

utation feedback informationJustification Feedback on performance (see eg step 8 in the APL scenario) pro-

vides the data on which reputations are built It needs to be collectedstored and made available to the reputation based trust service

Interaction Implements D14-54(c)Supports D12-53 D14-54(de)Depends on D12-55

ReqID D12-55Requirement The application business process SHOULD provide a trust feedback

opportunityJustification Reputations of entities and services are based on the feedback pro-

vided by users The application business process should ensure theuser is provided with an opportunity to give this feedback at relevantpoints in the process

Interaction Implements D14-54(de)Depends on D12-54 D12-510Supports D12-53

ReqID D12-56Requirement The trust management system SHALL provide a credential based

trust management serviceJustification To evaluate the trustworthiness of entities of services based on their

credentials The credentials determine the role an entity placed andthus in which setting they are trusted

Interaction Supports D12-51 D14-51(ab)Implements D14-51(c-e)

ReqID D12-57Requirement The trust management system SHALL provide a key performance

indicator based trust management serviceJustification Key performance factors capture (business) performance on specific

aspects such as delivery times etc Indicators which combine sev-eral factors provide valuable economical information about an entitywhich can be used as a source of trust

Interaction Supports D12-51Implements D14-53

ReqID D12-58Requirement The trust management system SHOULD be extendable with novel

trust metrics

Version 20

Justification As users trust requirements may evolve or be different in new settingsthe trust management system should be flexible enough to supportnew sources of trust This includes new metrics for existing servicesbut also support for new trust services

Interaction Depends on D12-51Supports D14-51

ReqID D12-59Requirement The trust management system SHALL provide trust policy formula-

tion supportJustification The flexibility of the trust policies can make it difficult for the user

to write policies To aid the user in formulating policies we plan toprovide a policy wizard

Interaction Supports D14-51(a-e)ReqID D12-510Requirement The TAS3 architecture SHALL support user identificationJustification Links requesters recommendations and feedback etc to names

(eg in policies) Needed to ensure authenticity of feedback andrecommendations

Interaction Supports all trust policy related requirementsReqID D12-511Requirement The legalcontractual framework SHALL support feedback data use

policiesJustification Data on which trust is based may itself be sensitive Technical pro-

tection is provided for some data such as credentials through trustnegotiation Protection of other data such as feedback on perfor-mance needs to be supported by contractpolicy which specifies theallowed usage of the (feedback) data Such contracts should con-form to new legislation in Europe that is being composed on scoringalgorithms

ReqID D12-61Requirement Intake Process (Person) The intake process MUST include docu-

mentation validation of identity and a technical user interfaceJustification We need to enroll people into the systemInteraction The Intake process reviews the execution of contracts compliance

ability and infratructure requirements To that end the intake processboth supports and is informed by all the other requirements (it pro-vides the evolution of the policies practices contract and ability tocomply of a prospective service provider)

ReqID D12-62Requirement Intake Process (organization) The intake process MUST include

documentation validation of identity verification of policies con-tracts and the capacity to comply as well as a technical user inter-face

Justification We need to enroll organizations into the system and review their in-frastructure and compliance capacity

Interaction The Intake process reviews the execution of contracts complianceability and infratructure requirements To that end the intake processboth supports and is informed by all the other requirements (it pro-vides the evolution of the policies practices contract and ability tocomply of a prospective service provider)

Version 20

ReqID D12-63Requirement Notice When information is collected it MUST be specified what

information is collected how it is collected who it might be sharedwith how it will be used and how it will be managed

Justification Required by the DirectiveInteraction Notice encompasses all foreseeable uses and sharing In many

ways it is dependent on all the following topics and they are depen-dent on it All requirements depend on and support D12-63

ReqID D12-64Requirement Collection LimitationData Minimization The TAS3 system and re-

lated processes MUST have appropriate limits on personal data col-lection to what is needed for legitimate identified and noticed busi-ness function The system must be supplemented by policies thatare articulated that limit employee access to information based onbusiness need

Justification Required by the DirectiveInteraction This section is informed by notice and use (below) but is also related

to security in terms of data minimization depends on and supports63 Depends on 65 Supports 612

ReqID D12-65Requirement Purpose specification The purpose(s) for collection MUST be clearly

specified The collection related to those purposes must be relevantand non-excessive

Justification Required by the directiveInteraction This is relatedcodependent on notice and collection limitationdata

minimization Which means this is relevant to not only those groupsthat collect information but also those that use the information asthey must appropriately minimize the data as well as secure it andcontrol access Depends on and supports 63 Supports 64

ReqID D12-66Requirement Consent Use and subsequent use of personal data MUST be com-

patible with the purposes specified and MUST be with the consent1

of the data subjectJustification Required by the DirectiveInteraction Dependent on notice and purpose specification applies torequires

subsequent consent capture 66 abstracts 67 Depends on andsupports 63 and 65

ReqID D12-67Requirement Subsequent consent capture If the use of information changes or

if there is a new use of information there MUST be a subsequentcapture of information

Justification Required by the DirectiveInteraction Contingent on business model and cross dependent on notice and

use 67 implements 66 Depends on and supports 63 and 65ReqID D12-68Requirement Access request process there MUST be a process to enable users

to request access (and possibly amend or correct) to types of infor-mation that have been collected and sharing of information Implicitin this requirement is the need to know where data came from or wassourced

Justification Required by the DirectiveInteraction Related to Collection Limitation and Notice Depends on and support

64 and 63

1It should be noted that consent often bears important adjectives of clear unambiguous or explicit From atechnical point of view this requires that the user opt in to the collection of personal information

Version 20

ReqID D12-69Requirement Compliant capture system Potential abuses to the system or con-

cerns of either users or organizations MUST be capturedJustification Emanates from requirements of the Directive The directive specifies

that a person must be able to complain which is not the same as aspecification of a complaint handling system

Interaction Should reflect the major elements of these requirements may alsobe joined to access mechanism Has to support all requirementswhich could be basis of compliant is also a proof element of 61

ReqID D12-610Requirement Redressoversight Processes Once a compliant is captured redress

MUST be possible Oversight process is a proactive version of thisconcept

Justification Emanates from requirements of the DirectiveInteraction Interdependent with all of the major elements of these requirements

in terms of oversight specific to breach or harm in terms of redressThis will be defined in legal but may require a BPM process to bemade effective Audit information in redress is required as a proofelement and is essential to oversight depends on all proof elementrequired by 61

ReqID D12-611Requirement Confidentiality Controllers and processors MUST have duties to

maintain confidentiality of information In some cases this will meanencryption especially in the UK

Justification Required by the DirectiveInteraction Horizontal requirement that attaches to use management and stor-

age of data Everything across the project that touches PII has thisrequirement including all aspects of legal It also supports D12-612

ReqID D12-612Requirement Security Appropriate security (technical and organizational) mea-

sures against unauthorizedunlawfulaccidental access modificationdisclosure destruction loss or damage to personal data MUST bein place

Justification Required by the DirectiveInteraction Horizontal across requirements as well as all entities involved in de-

velopment and operationsReqID D12-613Requirement Contract execution All participants to the TAS3 system MUST exe-

cute the appropriate TAS3 contract documentsJustification Required to enable a contract framework that binds all parties to the

use of appropriate technologies and the rights and obligations ap-pertaining to the transactions and uses of information

Interaction Depends on D12-614 D12-615 D12-616 D12-617ReqID D12-614Requirement Use of TAS3 Technology and Processes According to the contract all

parties MUST agree to use the appropriate TAS3 or TAS3 compatibletechnology and processes

Justification This is required to assure that all parties can exchange informationand engage in transactions in a compatible and secure manner

Interaction Supports D12-613ReqID D12-615Requirement Implementation of Required Policies According to the contract or-

ganizational participants in the TAS3 infrastructure MUST implementTAS3 defined or compatible policies specified in the contract

Version 20

Justification The contract framework is dependent on the need for appropriatepolices to support both the technology and the legal obligations setforth in the EU Directive and other applicable laws

Interaction Supports D12-613ReqID D12-616Requirement Agreement to be bound According to the contract all parties MUST

agree to be bound to the obligations they take on both as part ofthe TAS 3 infrastructure and as a result of transaction or choicesexercised through the TAS3 Architecture

Justification In order to give effect to the legal requirements of the Data Protec-tion Directive and other applicable laws all parties must agree tobe bound by both the infrastructure obligations as well as those thatarise through use of or transactions over the TAS3 architecture

Interaction Supports D12-613ReqID D12-617Requirement Binding Effect of technical processes All parties MUST agree to

be bound by the technical processes in the architecture to the extentthat they are working properly and have been appropriately disclosedand consented to

Justification The TAS3 architecture provides technical components that enhancetrust and facilitate transactions such as sticky polices The contentof the instructions contained in these policies or other technical com-ponents and the obligations associated with those instructions mustbe respected across the TAS3 architecture

ReqID D12-71Requirement A user sometimes needs to be able to authorise another user or

service to act on his behalfJustification A user needs to delegate to a portal to act on his behalf (step 7 of

the use case 2 in [22] Delegation from the user to the portal) Auser needs to delegate to his employer to access his eportfolio (step9 of use case 1 in [22] The employee authorizes his employer (HRmanager) to access the showcase of his ePortfolio)

Interaction Depends on D12-79 and implements D12-76ReqID D12-72Requirement Users sometimes need to be able to sign documents using their

rolesJustification It is a necessary functionality in step 8 of the use case 2 and step 6

of use case 1 Role based signing is requiredInteractionReqID D12-73Requirement The user must be able to prove who he is to any service and also be

sure that he is talking to the correct serviceJustification It is a necessary security need in step 1 of both use cases Mutual

authentication and authorisationInteraction Supports D12-716ReqID D12-74Requirement A user may need to present several authorisation credentials in order

to obtain a service eg a credit card and a club membership cardJustification It is a necessary functionality in step 2 of the use case 2 Attribute

aggregation of credentials

Version 20

Interaction This is related to Requirement D12-75 but orthogonal to it WhilstD12-74 is stating that multiple credentials from multiple issuers maybe needed D12-75 is saying that each credentials should be re-leased incrementally even if they come from the same issuer HenceD12-74 depends on D12-75 and implements D12-76

ReqID D12-75Requirement Users should only need to provide the minimum of credentials that

are needed to obtain a service and no moreJustification It is a necessary condition in step 2 of the use case 2 and step 3 of

use case 1 Minimum of credentials in order to RegisterInteraction This is the user pushing his minimum credentials to a service

provider It is related to requirement D12-717 as the system mayuse similar mechanisms to accomplish both requirements D12-75hence depends on D12-717 supports D12-74 and implementsD12-76

ReqID D12-76Requirement Users must have the authorisation to perform any actionJustification It is explicit in step 1 of the use case 1 and implicit in most stepsInteraction This is a very generic high level requirement and abstracts require-

ments D12-71 D12-74 D12-75 D12-79 D12-710 D12-712D12-713 D12-715 D12-717 D12-724

ReqID D12-77Requirement Users should be able to dynamically set their privacy policiesJustification Its in step 2 of the use case 1 Set the userrsquos privacy policy for Per-

sonal Identifying Information (PII) and consent to use this PII andstep 3 of use case 2

Interaction Depends on D12-719 and supports D12-726ReqID D12-78Requirement Different service providers should not be able to collude together to

determine who a pseudonymous user is without the users consentJustification Service providers could jointly profile the user Related to step 4 of

use case 1Interaction May conflict with Requirement D12-718ReqID D12-79Requirement Credentials should be revocableJustification If a user delegates his credential to another person or process he

must be able to revoke this delegation if either the delegate abusesits privileges or the user changes his mind

Interaction Supports D12-71 and D12-714 and implements D12-76ReqID D12-710Requirement Credentials should be targetable to a specific relying partyJustification A credential owner does not wish a credential receiver to use the

credential on his behalf It is related to step 4 in use case 1Interaction implements D12-76ReqID D12-711Requirement The system must support the merging and enforcement of multiple

policiesJustification It is in step 5 of use case 1InteractionReqID D12-712Requirement The system must be able to pull additional user credentials on de-

mandas requiredJustification It is in step 6 and 7 of use case 1Interaction Depends upon D12-713 Supports D12-715ReqID D12-713

Version 20

Requirement The system must be able to determine where to pull additional cre-dentials from

Justification It is in step 6 of use case 1Interaction Supports D12-712 and implements D12-76ReqID D12-714Requirement One service provider should be able to subcontract (delegate) to an-

other service provider to get work done on behalf of the original userJustification Another instance of delegation of authority this time service to ser-

viceInteraction This is similar to D12-71 only it is system to system rather than

person to person It may depend on D12-79ReqID D12-715Requirement Users should be able to push their credentials to the system dynam-

ically when more are neededJustification Step 3 of use case 2 Consent to collect additional PII or ask user to

provide itInteraction Supports D12-712 The authorisation system should be able to pull

user credentials and accept pushed user credentials and these mayneed to be supplemented at any time with additional user creden-tialsemphimplements D12-76

ReqID D12-716Requirement User should be able to use different pseudonyms in order to protect

their privacyJustification Step 3 of use case 2 User must be able to act with different personas

with different vacancy profilesInteraction May depend on D12-73ReqID D12-717Requirement Credentials should be incrementally released as trust is establishedJustification Step 4 of use case 2 Find possible Service Providers that provide

the right sort of jobs via the portal Find out which are trustworthyNeither party must reveal too much information about themselves

Interaction May use similar mechanisms to D12-75 as this requirement re-quires both the user and the remote service provider to push theminimum of their credentials to the other party It implements D12-76

ReqID D12-718Requirement A service provider should not be able to link together the sequential

requests of a user without the users consentJustification Services should not be able to profile users without their consentInteraction may conflict with D12-78ReqID D12-719Requirement Service providers should be able to update their policies dynamically

without having to bring down the systemJustification Service providers often need to be able to provide 2424 provision of

service and bringing the system down to change the policy is not fastenough or pro-active enough

Interaction Supports D12-77 in that a user policy may be one of the SPs poli-cies so D12-719 must be met before D12-77 can be fulfilled

ReqID D12-720Requirement Service providers should be able to distribute policy administration

between multiple administratorsJustification Different administrators have different skills and knowledge and

therefore are more competent to set particular polices Furthermoreit can be too big a job for anyone person to do

Version 20

Interaction Could support Requirement D12-72 by having role based signingof policies

ReqID D12-721Requirement The system needs to be resilient to fraud or mistakes by users and

administratorsJustification Organisations have a legal duty of care to prevent fraudInteractionReqID D12-722Requirement The authorisation system needs to have an escape mechanism in

emergencies (so called break the glass policies)Justification For example when a patient is taken unconscious to an emergency

department and has not authorised the doctor on duty to access hispersonal health records the doctor may need to get access to thisregardless of the patients policy

Interaction Depends on D12-723ReqID D12-723Requirement The authorisation system needs to be able to make decisions based

on the current state of the application andor systemJustification Systems are naturally dynamic and authorisation systems need to

be able to cater for thisInteraction Supports D12-722ReqID D12-724Requirement The authorisation system should securely recordaudit the decisions

that have been made in a tamperproof and confidential mannerJustification Auditors and criminal investigators may need access to these events

post-facto and they need to be assured that the logs have not beentampered with

Interaction Supports D12-725 implements D12-76ReqID D12-725Requirement Auditing needs to be dynamic and adaptive to changes in the system

andor environmentJustification If the system detects an attack then the level of auditing should au-

tomatically increaseInteraction Depends on D12-724ReqID D12-726Requirement A user must provide consent for the use of his private data and cre-

dentialsJustification It is part of data protection legislation and in step 2 of the use caseInteraction Depends on D12-77ReqID D12-727Requirement Sensitive tasks must be split between multiple usersJustification Separation of duties is a well known procedure for ensuring the se-

curity and safety of sensitive tasks It is also required by the businessprocess managers in WP3

Interaction

ReqID D12-81Requirement The pilots MUST have a gateway to access the TAS3 infrastructureJustification Either the requesting applications or the providing or responding ap-

plications shall be able to access TAS3 over a unified interface Bythis it is also possible that other applications in the future can beeasily integrated into TAS3

Version 20

InteractionReqID D12-82Requirement Legacy databases SHALL be able to provide their data and service

to TAS3Justification TAS3 shall be open for legacy systems like legacy databases To

provide such an easy way of integration there must be an interfaceespecially for legacy databases

Interaction Depends on D12-81 which specifies the ADPEPReqID D12-83Requirement An end-user SHALL be able to access TAS3 functionality through a

business processJustification Many workflows in organisations use a business process engine to

keep track of the workflow or business process Since TAS3 legit-imized service providers are part of these workflows they shall beeasily integrated into the business process

Interaction Depends on D12-81 which specifies the ADPEPReqID D12-84Requirement An end user SHALL be able to access TAS3 services through a spe-

cial TAS3 generic client without having to use a complete BusinessProcess Engine

Justification Not in every case the user accesses TAS3 through a business pro-cess engine Other possible clients are smart phones web front-endor fat clients To also support these types of clients we need a moregeneric client

Interaction Depends on D12-81 which specifies the ADPEPReqID D12-85Requirement An end user SHALL be able to access and manage herhis policiesJustification TAS3 user will get into contact with different layers of policies Poli-

cies may be user centric organisational or even TAS3 wide For usercentric policies the user needs a special front-end and back-end tomanage herhis policies

Interaction Depends on D12-81 which specifies the ADPEPReqID D12-86Requirement An end user SHALL be able to store and modify its data in a reposi-

tory for person related data This repository has to be reachable in aTAS3 secured and trusted way

Justification Among other things TAS3 is about storing and exchanging personrelated data in a secure and trusted way To store such data weneed special TAS3 adapted repositories

Interaction

ReqID D12-91Requirement Processes MUST have secure access to data drawn from a variety

of distributed sources but only be able to access the data they needJustification This is needed to ensure the efficiency and security of the process

accuracy and support for data protection requirementsInteractionReqID D12-92

Version 20

Requirement Users MUST be able to set view control and change policies fortheir data at a variety of levels down to the lowest (field) level fromaccepting clearly-formulated pre-set policies to adding fine-grainedpolicies to specific sets of data they must clearly understand theimplications of this policy choice

Justification This is needed for the user to exercise control and to comply withprivacy legislation Users will want the same data to be used in avariety of processes so may want to add context-specific policies tohow it will be used

Interaction Supports D12-91 D12- 94 D12-96 Depends on D12-93ReqID D12-93Requirement Users MUST have easy and easily-understood access to the sys-

tem without the need for overly-complex authentication and autho-rization processes preferably via SSO

Justification This is necessary to support users support for the system if it istoo complex to access they will not use it unless they have to or willtake measures to simplify access that may compromise security (egwriting down passwords) however they also have to feel trust in thesystems security

Interaction Supports D12-92 D12-94 D12-913ReqID D12-94Requirement Users MUST be securely authenticated and authorised before any

access to data is allowedJustification The system needs to know that only appropriate access is being re-

quested and users must be matched against the correct sets of dataThis complies with legal and ethical requirements and is protectionagainst fraud There needs to be a provision for different levels ofauthentication and trust

Interaction Supports D12-91 D12-95 Depends onemphAbstracts D12-93ReqID D12-95Requirement There MUST be a secure and reliable audit trail showing who ac-

cessed user PII when and for what purpose and whether anychanges were made and this audit trail must in turn be secure andonly accessible by authorised individuals or service providers

Justification Necessary for investigation of breaches of security or any official en-quiry especially into breaches of data protection legislation or sus-pected fraud This is an administrative tool rather than the userinterface

Interaction Depends on D12-92 D12-94 Supports D12-98ReqID D12-96Requirement Users MUST be able to set specific policies for all possible data-

requesters from highest level (country) down to the lowest level(named actor) including accepting clearly-formulated pre-set poli-cies for common data-requesters they must clearly understand theimplications of this policy choice

Justification This is one of the main objectives and USPs (unique selling points)of TAS3 for users This should also allow for combinations of policiesand include a mechanism for when different policies are interactingat the same time

Interaction Supports D12-92 Depends on D12-93 D12-94ReqID D12-97Requirement Users MUST be able to check (read) their personal data stored in all

Justification Users have the legal right to know from the system what data isstored about them and to challenge it if it is incorrect

Version 20

Interaction Depends on D12-91 D12-93 D12-95ReqID D12-98Requirement Users MUST be able to see who has requested access to which of

their PII data and whether or not access was grantedJustification Users trust in the system depends on this it is the main reason for

them to engage with TAS3 They also have the legal right to knowwho has had access to personal data

Interaction Depends on D12-95 D12-94 Supports D12-92ReqID D12-99Requirement Users MUST be able to change the policies attached to their PII data

at any timeJustification User requirements and situations may change and the policies for

their data may change with them Evolving legal requirements alsomake this a necessity Includes interactive changes such as re-sponses to consent questions

Interaction Depends on D12-92 D12-96ReqID D12-910Requirement The policy management user interface MUST meet the highest

known current standards (complying with current best practice oninterface design w3c guidelines)

Justification Policy setting is a complex task and the implications of decisionsmade should be very clear to the user The policy interface is themain interface for users and thus the showpiece of TAS3 most of therest of the exchanges is performed by back office systems Usersfrom a variety of different social backgrounds and educational levelsshould be able to work easily with this interface To comply with UKSENDA legislation any user interface must adhere to strict accessi-bility guidelines

Interaction Supports D12-92 D12-93 D12-96 D12-98 D12-99ReqID D12-911Requirement Interoperability between different systems MUST be established to

Justification Not all systems used in the pilots use the same standards formatstables or fields As the system will be web-based we need to ensurethat all legacy systems are web-service compliant and build in anynecessary interfaces to support interoperability which is not currentlyin place Any existing mandatory security mechanisms must be en-compassed Service Providers need to be able to provide data in aform that can be accepted by a Service Requester

Interaction Supports D12-91 D12-93ReqID D12-912Requirement Persistent and unique electronic means of identification MUST be

provided for usersactors of the TAS3 infrastructureJustification The system must be able to consistently uniquely and positively

identify all usersactors within the TAS infrastructure to ensure dataintegrity and correct levels of access permission

Interaction Supports D12-93 D12-94 D12-95ReqID D12-913Requirement Actors (data-requesters service providers) MUST be able to connect

Justification This is necessary to provide services access to the TAS3 infrastruc-ture and preserve confidentiality of data

Interaction Depends on D12-91 Supports D12-93

Version 20

ReqID D12-914Requirement Back office services must be invisible to the userJustification While users must be able to know and verify how their data has been

used this needs to be done seamlessly users do not need to seethe internal workings of the system

Interaction Supports D12-93 Depends on D12-911ReqID D12-915Requirement TAS3 specific processes must not adversely affect performance or

add complications to existing processes from the users viewpointJustification For users the overall process must remain smooth speed and per-

formance must not be impaired by the trust and security processesIf additional complications and extra steps are added users are likelyto bypass or ignore them

Interaction Supports D12-93 D12-914ReqID D12-916Requirement Data within the ecosystem SHOULD not be copied or duplicated it

should be stored once used many timesJustification Copying data leads to version control issues issues with deletion

and issues with auditing and journalingInteraction Depends on D12-91

ReqID D12-101Requirement The TAS3 architecture MUST support perpetual (ie event-driven

periodical) and automated compliance testing of servicesJustification Service-oriented applications are characterized by great dynamism

eg service implementations and service bindings may change atruntime In the reference scenarios the services (instances) thatparticipate in the interaction may change independently and withoutinterrupting the service provision (eg a new implementation of afunctionality can be deployed the quality of the new implementa-tion needs to be assessed dynamically) Testing strategies that arebased only on offline techniques are therefore inadequate and in factimplementing run-time checking mechanism is generally recognizeda best practice in service-oriented settings

Interaction Depends on D12-108 in that continuous automatic testing requiresprecise models to be available for each service involved in a chore-ography

ReqID D12-102Requirement The TAS3 infrastructure SHALL detect service failures in granting or

denying access to resources with respect to their manifested policiesJustification This kind of failures is especially critical as the trustworthiness of

TAS3 heavily depends on proper handling (management and en-forcement) of policies

Interaction Depends on D12-108 this requirement can only be fulfilled if poli-cies are manifested by services as part of their specification

ReqID D12-103Requirement In a TAS3 choreography error messages returned after a request of

a resource (eg ldquoaccess deniedrdquo message) MUST be identifiable assuch eg through a special flag in the message header

Version 20

Justification Applications might masquerade error messages for user-friendliness(eg they could produce a ldquopretty formattedrdquo page) nonetheless theTAS3 architecture needs to be able to unambiguously recognize errormessages without the need to delve into the semantics of the pay-load of the message If we consider for instance the APL scenariocertain operations (such as accessing data or using functions) mustbe allowed only upon exhibiting corresponding credentials (eg tofill-out portfolio information or to read certain portions of a portfolio)

Interaction Supports R101 as test automation needs an oracle to determinethe successfailure outcome of a test execution

ReqID D12-104Requirement Demonstrators SHALL provide good levels of end-user perceived

trustJustification The success of any information system architecture must be based

not only on technology schemes standards and protocols but alsoon usersrsquo perceptions We need to assure that TAS3 services areimproved in terms of perceived trust

Interaction Depends on D12-105 D12-106ReqID D12-105Requirement Demonstrators SHALL provide good levels of end-user perceived

service qualityJustification The success of any information system architecture must be based

not only on technology schemes standards and protocols but alsoon usersrsquo perceptions Thus we need to assure that TAS3 ser-vices are improved in terms of perceived service quality from a non-technical perspective

Interaction Supports D12-104 D12-106 D12-107ReqID D12-106Requirement Demonstrators SHALL provide good levels of end-user perceived us-

abilityJustification Usability is one of the most important validation issues for TAS3 ar-

chitecture It is necessary to assure that TAS3rsquos services achievegood usability levels

Interaction Supports D12-105 D12-104 Depends on D12-107ReqID D12-107Requirement Demonstrators SHALL provide good levels of accessibilityJustification According to several EUrsquos agreements accessibility must be consid-

ered especially in the case of public services (eg health) Thusaccessibility must be analyzed and taken into account in TAS3rsquos ser-vices

Interaction Supports D12-106ReqID D12-108Requirement Services that are to participate in a TAS3 choreography MUST be

accompanied with models describing their characteristicsJustification These models are part of a TAS3 ldquogovernance contractrdquo and consti-

tute the basis on which the services are verifiedInteraction Supports D12-101 D12-102 and D12-109ReqID D12-109Requirement All services willing to participate in a TAS3 choreography SHOULD

be validated against the accompanying models

Version 20

Justification Mandating that service characteristics (eg their behaviour theirextra-functional characteristics) be documented enables a numberof (automated rigorous) validation activities that are key to enhancethe trustworthiness of services In both the reference scenarios allparties that interact should have gone through a preliminary valida-tion phase Furthermore the outcome of this validation can also beused when selecting providers based on their trustworthiness (egat step 3 of the APL scenario as well as at step 4 of the ML scenario)The type of validation and the extent to which such validation can becarried out depends on what information is included in the modelsattached to the services

Interaction Depends on D12-108 which mandates that services that are toparticipate in a TAS3 choreography must be accompanied by speci-fications

ReqID D12-121Requirement All developers testers and users MUST understand significant parts

of the complete system at least at the conceptual levelJustification TAS3 fundamentally secures business processes end to end Iso-

lated components may provide a tiny part of the end-to-end securitybut are still part of a chain or mesh that can break Knowledge out-side the component focus is required ahead of time so that expen-sive basic design mistakes can be avoided

Interaction Depends on D12-122ReqID D12-122Requirement All developers testers and users MUST have access to all project

documentation regardless of origin target audience or assumed rel-evance

Justification The scope of the project is too wide to predetermine which peopleneed what document so the distribution is going to be pull instead ofpush

Interaction Supports D12-121ReqID D12-123Requirement Project participants MUST be left free to choose when and how to

perform their contractual duties within reasonJustification TAS3 for nearly no participant is a 100 workload Care needs to

be taken that no process is pushed onto the participants that woulddictate their daily work process which takes place in another organi-sation

InteractionReqID D12-124Requirement A hierarchical escalation structure MUST be in place to raise im-

portant andor urgent events to organisational levels above non-responsive ones

Justification When reasonable limits on timeresource allocation flexibility are ex-ceeded and project progress is threatened other partners daily op-eration may need to be altered

Interaction Supports D12-123ReqID D12-125Requirement All developers and testers MUST maintain their component docu-

mentation in a central repository that at the very least MUST be cur-rent for software that has been released outside the developers lab

Version 20

Justification When any developer tester or user wants insight in what a compo-nent does (s)he needs to be able to directly get the answer

Interaction Supports D12-121 D12-122ReqID D12-126Requirement E-mail as message system andor dissemination system MUST be

reduced as much as practical and replaced by on-demand (pull) sys-tems

Justification Twofold it is often not possible to determine for exactly which peoplea message is important or will become important yet broadcast to allis no option and most people already receive too many messagesso that the message would be likely lost anyway

Interaction Supports D12-122 D12-123 D12-124ReqID D12-127Requirement Released components MUST be checked and re-checked for correct

operation in the network environment and developers MUST be keptup to date as of the performance of their released component

Justification Even when a component adheres exactly to the specifications it mayhappen that situations arise where the specifications turn out to bewrong or incomplete Unit tests are only run in isolation Continuousintegration has the power to reveal integration problems at an earlystage

Interaction Depends on D12-124ReqID D12-128Requirement A controlled environment MUST be available to perform complex use

cases and abuse cases of components in an orchestrationJustification Situations will arise where unexpected events such as component

failures or unspecified environmental conditions interfere with a setof components Due to complex relationships and cause-and-eventpatterns problems may appear which are hard to create or foreseein isolated unit testing It needs to be demonstrated that the orches-tration is resilient to intentional abuse

Interaction Supports D12-127ReqID D12-129Requirement Components MUST be configurable in such a way that they inten-

tionally perform in abnormal waysJustification To fully test a constellation for resilience against malfunctions com-

ponents must be exposed to failing peers We do not want to specif-ically develop mock components just for abuse testing when the realthing is available and ldquoknowsrdquo exactly what nasty failure modes itwould have

Interaction Supports D12-127ReqID D12-1210Requirement Multiple controlled environments SHOULD be available to rig parallel

use and abuse setups with different components andor configura-tions

Justification It is cumbersome to schedule tests on one central rig and tell devel-opers to postpone testing until the rig has the right configuration in aspecific time window

Interaction Supports D12-127ReqID D12-1211Requirement An automated process SHOULD be available that allows hands-off

setup of a complete controlled environment in a pre-defined configu-ration running a set of use and abuse cases and report the results

JustificationInteraction Supports D12-127

Version 20

ReqID D12-1212Requirement Components MUST come with a sub-component (ldquoinstallation

scriptrdquo) which allows partial automation of the installation and con-figuration of the component

Justification With the central useabuse rig central to the project there is no ex-cuse to rely on written textual material for very regular routine in-stallation and configuration procedures Given the controlled envi-ronment assumptions may be made about available resources andlocations that in a more generic case would need to be left to theinstalling person

Interaction Supports D12-1211ReqID D12-1213Requirement Users MUST be able to verify that a constellation of components

behaves according to their specificationsJustification TAS3 aims to demonstrate usability in user scenariosInteraction Depends on D12-128

Supports D12-1215ReqID D12-1214Requirement Specific test scenarios MUST be made available to automatically test

constellations of componentsJustification Without automation testing remains a one-off event that cannot be

used to continuously validate the quality of a constellation in produc-tion

Interaction Implements D12-1213ReqID D12-1215Requirement Users MUST be able to validate that a constellation of components

behaves according to their scenarioJustification TAS3 aims to solve user problems expressed in scenarios but we

need to make sure that the scenarios are correctly specifiedInteraction Depends on D12-1213ReqID D12-1216Requirement Most procedures and automated functions required for the test bed

MUST allow to be carried over to a production situation for perma-nent constellation monitoring

Justification TAS3 Quality of Service requirements assume continuous monitoringof the working system to provide KPI for quality assessment andtrust perception

InteractionReqID D12-1217Requirement All components MUST come with documentation according to es-

tablished standards and MUST follow an established delivery proce-dure

Justification To facilitate integration and production setup modules need to beroutinely handled by people not necessarily knowing the particulardetails of each module This holds both for externally provided andin-house manufactured components

Interaction Supports D12-125Abstracts D12-1212

ReqID D12-1218Requirement All external components used in TAS3 MUST have proper documen-

tation and installation procedures available and one responsible part-ner per component MUST keep them current

Version 20

Justification It cannot be left to the integrator or production maintainer to takeon the burden of finding out exactly how one of the project partnerswants to set up an external component And more than one partnermay need a conflicting setup Component ownership

InteractionReqID D12-1219Requirement All components MUST come with documentation broken down in

sections or reading guides for 1 component developers 2 peercomponent developers 3 system administrators 4 users and 5user managers

Justification People at all levels may need to refer to the module Providing thisindex is little work for people familiar with the component and impos-sible for newcomers Having a clear management summary meansoverall trust in the system may improve

Interaction Implements D12-122ReqID D12-1220Requirement Training sessions for developers and system managers MUST be

providedJustification It cannot be expected from all people that they can without training

pick up and learn the important (security and business) aspects ofall components Expert help is required

Interaction Implements D12-121ReqID D12-1221Requirement Change management MUST be enforced on core integration re-

sourcesJustification Where changes have the potential to cause far-reaching conse-

quences not necessarily apparent to the changer we need to man-age the change proposal

Interaction Supports D12-122 D12-124 D12-126Conflicts with D12-123Abstracts D12-125

ReqID D12-1222Requirement Short medium and long term planning MUST be provided for the

component developers to set their prioritiesJustification The project-wide deliverable plan is too coarse to suggest daily

weekly and monthly development activities especially with respectto the interactions between components from different developersand the advancing insight gained during the project

Interaction Supports D12-121 D12-123Implements D12-124

ReqID D12-1223Requirement A single central place MUST be available where all known issues

and defects of all components are administratedJustification With the projects focus on integration even individual component

developers need to be very aware of problems with their componentoutside the laboratory And users of the component (peer develop-ers) must be aware of problems with their peer component even ifthey have not encountered them yet

Interaction Supports D12-122 D12-126 D12-1221Conflicts with D12-123

ReqID D12-1224Requirement One resource MUST be available which authoritatively lists all avail-

able and required components external and internal uniquely iden-tifiable throughout their life cycle

Version 20

Justification For project planning and progress monitoring a current overview ofthe purpose status and use of all components needs to be main-tained

Interaction Supports D12-121 D12-1223ReqID D12-1225Requirement As part of a component catalog an interface catalog MUST be cen-

trally availableJustification Not all components are designed to talk to all other components

Designed or planned peer components share one interface whichmust be documented where possible ahead of implementation

Interaction Supports D12-1222ReqID D12-1226Requirement At least one reference constellation SHOULD be available which al-

lows application-independent components to be integration-testedwithout a specific demonstrator scenario

Justification It can be expected that application-dependent modules put less de-mand and stress on an infrastructural component than what the in-frastructural component was architecturally designed to cope with

Interaction Supports D12-127ReqID D12-1227Requirement A common reference system MUST be available to uniquely identify

data object types cross-applicationJustification Policies are used to specify what is allowed to happen with data

Unknown data types mean the data is not allowed to be stored orprocessed and must be rejected It is unlikely that any top-downstandard will develop soon which unifies data types Applications canbi-laterally agree on data types by using unique identifiers allowingsuccesfull forwarding of data and policies even if the data format itselfis as yet unprocessable

InteractionReqID D12-1228Requirement A transformation service SHOULD be available to help applications

use data which is not natively known to themJustification If parties have bi-laterally agreed on a unique data type they can

forward each others data while maintaining trust and privacy rulesBy adding transformations they can also process and manipulatethe data according to trust and privacy rules

Interaction Depends on D12-1227ReqID D12-1229Requirement On request developers MUST release a component which conforms

to the standard framework (documentation installation procedureinterface specification) even if this means releasing a mockup com-ponent without real functionality

Justification Peer developers often need to use a stub component to test theirown component Instead of developing the same stub over and overagain it is much more effective and efficient to have an early non-functional release of the actual component

Interaction Supports D12-1222 D12-1223ReqID D12-1230Requirement Central resources MUST be updatable by all relevant peopleJustification TAS3 is too small a project to allow dedicated full-time support staff

When a central resource is found being inadequate or in error ev-erybody relevant to the resource should be able to change it Theresource editor then can after the fact inspect the change and pos-sibly undo it or re-change This avoids resource update bottlenecks

Version 20

Interaction Supports D12-123 D12-124 D12-125

Version 20

D Existing SolutionsThe following is the list of software that provide existing solutions to some of the solved problems in TAS3

Solutions that solve the same problem that provide alternative solutions are listed in a single table one after theother Every separate table is another solution that will be adopted by the partners in TAS3

The following includes the complete list of existing solutions that will be used by WP 34578910 and 12The VUB team in WP2 has also provided us with existing solutions The solutions that will be utilized by theArchitecture team is included in Deliverable 21 [18]

Name of Solution Intalio Designer BPMS and TempoLink httpwwwintalioorgAccess open sourceopen standardFunctionality Graphical Process Modelling Tool based on BPMN

(Business Process Modelling Notation) allows to de-ploy BPEL processes which can be executed by Intal-ioBPMS Intalio Tempo is a enhancement of the IntalioSuite which supports human activities

Limitations with respect to TAS3 Open source part does not include XForms editor datamapper transformation into BPEL and automatic de-ployment IntalioBPMS does not support security is-sues like authorization access rules and their en-forcement Adaptation is only supported in a simpleform ie change a web service before its call withoutnewly deploying the process Tempo does not yet sup-port federated identitySSO

Related Requirements Fulfills D12-31 through D12-33 partially fulfills D12-34

Justification of Selection In main parts it is open source software Intalio pro-vides graphical modeling as well as process executionengine and integrates both parts The process model-ing tool together with human activities is a very com-prehensive and comfortably usable tool

Name of Solution Oracle BPM-SuiteLink httpwwworaclecomtechnologiesbpm

bpm-suitehtmlAccess proprietaryFunctionality Business Process Modelling and Management in a

SOALimitations with respect to TAS3 Not open source software not sufficient support of pro-

cess adaptations and process securityRelated Requirements Fulfills D12-31 through D12-33 partially fulfills D12-

34Name of Solution IBM Web Sphere Integration DeveloperLink httpwww-306ibmcomsoftware

integrationwidAccess proprietaryFunctionality Business Process Modelling and Management in a

34Name of Solution ActiveBPEL Community Edition EngineLink httpwwwactivevoscom

community-open-sourcephp

Version 20

Access ProprietaryFunctionality Business Process Modelling and Management sup-

porting BPEL (Business Process Execution Language)Limitations with respect to TAS3 Not open source software not sufficient support of pro-

cess adatations and process securityRelated Requirements R31 through R33Name of Solution jBPMLink httpwwwjbosscomproductsjbpmAccess Open sourceFunctionality Business Process Modelling and ManagementLimitations with respect to TAS3 Lack of inherent web service support not sufficient

support of process adaptations and process securityno enhanced support for human activities

Related Requirements fulfills D12-31 fulfills D12-32 and D12-34 with limi-tations

Name of Solution PERMISLink httpseccskentacukpermisAccess open sourceopen standardFunctionality - Allows one user to dynamically delegate access right-

spermissions to another user and allows a process tobe split into two or more tasks that have to be under-taken by different entities (eg manager and clerk)- Has a PDP and a CVS Allows credentials to be pulledor pushed Supports separation of duties and statebased decision making Supports delegation of au-thority Has an XACML interface to the PDP SupportsXACML formatted obligations

Limitations with respect to TAS3 - Based on using X509 ACs stored in LDAP directoriesStart up can be time consuming if large audit trails arepresent- Originally build to support authorisation credentialsencoded as X509 attribute certificates Currently onlyhas limited support for SAML formatted attribute asser-tions (eg Delegation only works with ACs and not withSAML assertions)- The policy language is not standardized- Is purely RBACABAC based though could be ex-tended to support DAC

Related Requirements Fully fulfilled D12-76 D12-79 D12-724 Partially ful-filled D12-35 D12-36 D12-71 D12-72 D12-712-15 D12-721 D12-723

Justification of Selection - Open source software based on XACML-Has more required functionality than any other pack-age Is modular and allows plug and play with anXACML PDP

Name of Solution KULeuvens demonstrator frameworkLink To be providedAccess open source

Version 20

Functionality Demonstrator framework that is able to illustrate theTAS3 concepts It currently provides a proof-of-conceptimplementation of the following TAS3 concepts break-the-glass policy enforcement user friendly policymanagement transparency of executed business pro-cesses secure communications

Limitations with respect to TAS3 The service provider discovery mechanism of thedemonstrator framework does not yet support trust andprivacy policy negotiation

Related Requirements D12-21 D12-25 D12-26 D12-37 D12-105D12-121

Justification of Selection The demonstrator framework is proven technology thatcan easily be extended During the first year of TAS3 the demonstrator framework has been extended withsupport for complex business processes the break-the-glass function and advanced policy enforcement

Name of Solution Belgian e-ID cardLink httpeidbelgiumbeAccess open source and proprietary for Belgian citizensFunctionality authentication mechanism used as a token that sup-

ports client authenticationLimitations with respect to TAS3 no limitations specific to TAS3

Related RequirementsJustification of Selection It is the authentication token that has the highest level

of assurance that is currently available in the consor-tium

Name of Solution Encryption Algorithm AESLink httpcsrcnistgovpublicationsfips

fips197fips-197pdfAccess open sourceFunctionality encryption and decryption of dataLimitations with respect to TAS3 no limitations specific to TAS3

Related RequirementsJustification of Selection It is a standard encryption algorithm

Name of Solution Tulip Trust Management systemLink httpdiescsutwentenl˜czenkom

tulipdocAccess open sourceFunctionality Credential based trust management systemLimitations with respect to TAS3 Credential based trust management only no support

for other trust metrics Does not use the TAS3 trustservice methodology

Related Requirements D12-56Justification of Selection Compared to other existing CTM systems TuLiP excels

in key aspects for TAS3 flexibility of the syntax userauthonomy and automation

Name of Solution PostgreSQL

Version 20

Link httpwwwpostgresqlorgAccess Open sourceFunctionality Relational database Can be used to gather reputation

feedback information and make it available to the repu-tation based trust management engine

Limitations with respect to TAS3 Does not provide complex operations required forbehaviour-based trust policies Not yet a web serviceNo support for integrity of information Possibly re-quires strict access controls to prevent rigging of dataDoes not support users privacy policies

Related Requirements D12-53 D12-54Name of Solution ORACLELink httpwwworaclecomdatabaseindex

htmlAccess ProprietaryFunctionality Relational database Can be used to gather reputation

Related Requirements D12-53 D12- 54

Version 20

Name of Solution SunXACMLLink httpsunxacmlsourceforgenetAccess Open sourceFunctionality - XACMLv2 policy language reference implementation

Can be used as a basis for the Trust PDPLimitations with respect to TAS3 - Supports the XACMLv2 standard but does not deal

with trust or other TAS3 extensions- Does not support separation of duties state baseddecision making- Requires a separate CVS to validate user credentials- Requires separate components to pull and push cre-dentials- Not good at supporting pure RBAC policies- No good user interfaces for writing policies

Related Requirements D12-51 D12-76Justification of Selection - Well known open source XACML implementation

- Uses an OASIS standard policy language- Supports a wide range of access control policies- Can be combined with PERMIS

Name of Solution Trust Policy WizardLink httpi40virt02ipdukadeCoSimAccess Open sourceFunctionality Allows guided interactive formulation of trust policiesLimitations with respect to TAS3 Only supports behaviour-based trust policiesRelated Requirements D12-59Justification of Selection Providing a wizard is a powerful yet straightforward way

of supporting user selected policies We do not excludethe possibility for more integrate solutions such as egnatural language policy editors

Name of Solution Shibboleth IDP and SP software for SSOLinkAccess Open SourceFunctionality Provides user authentication and SSO using SAMLv2Limitations with respect to TAS3 Not easy to install or configureRelated Requirements D12-73 D12-718Name of Solution SAMP PHPLinkAccess Open SourceFunctionality Provides user authentication and SSO using SAMLv2

Reputedly easy to useLimitations with respect to TAS3 Not sure will need to investigateRelated Requirements D12-73D12-718Name of Solution LassoLink httplassoentrouvertorgAccess Open SourceFunctionality Liberty Alliance Library support SAML2 ID-WSF ID-

SIS Personal Profile and HR (based on Europass CVprofile)

Limitations with respect to TAS3

Related Requirements D12-108 D12-102

Version 20

Justification of Selection OpenSource certified by Liberty Alliance OASIS re-garding SAML2 support Supports the HR ID-SIS draftprofile which is a profile of the European Europass CVinitiative (promoted by CEDEFOP EU Agency) Notethat this HR profile is also supported by ZXID

Name of Solution AuthenticLink httpauthenticlabslibre-entrepriseorgAccess Open SourceFunctionality Liberty Alliance compliant ID Provider support

SAML2 ID-WSF ID-SIS Personal Profile and HR(based on Europass CV profile)

Related Requirements D12-77 D12-710 D12-726 D12-727 D12-91D12-916 D12-91 D12-916 D12-108 D12-102

Name of Solution LARPELink httplarpelabslibre-entrepriseorgAccess Open SourceFunctionality Liberty Alliance Reverse Proxy It allows any website to

use Liberty Alliance features (Identity federation SingleSign On and Single Logout) without changing the codeof the service provider itself Its Liberty Alliance com-pliance relies on Lasso It also supports the draft HRID-SIS which allow mapping of an existing applicantre-cruiting form with user Europass CV data stored by an-other service in the Circle of Trust with privacy securedby ID-WSF

Related Requirements D12-82 D12-911 D12-914 D12-916 D12-1228

Name of Solution CVT (CV Transcoding Web Service)Link httpcvteife-lorgAccess Open SourceFunctionality Interoperability gatewaybackoffice service which allow

transformation of CVePortfolio related data from oneformat to another one Support Europass CV IMSePortfolio Netherlands LinkedIn hResume HR ID-SIS

Name of Solution TrustBuilder2LinkAccess Open SourceFunctionality Provides trust negotiation and gradual release of cre-

dentials It is written in Java and allows plugin modulesfor policy evaluation and negotiation strategy It allowscredentials and policies to be written in any languageproviding the correct plugins are available

Limitations with respect to TAS3 Not sure will need to investigateRelated Requirements D12-717Justification for Selection Whilst we will probably need to write some of our own

plugins in order to support the policies and credentialsof TAS3 nevertheless we anticipate that the Trust-Builder2 infrastructure will support this

Version 20

Name of Solution Fedora RepositoryLink httpwwwfedora-commonsorgAccess open sourceFunctionality Repository for all kind of data Accessible through a

web service interface Can be integrated in a SOALimitations with respect to TAS3 Is not aware of TAS3 secure or trusted communicationRelated Requirements D12-86Justification of Selection - The Fedora repository can be completely integrated

in a SOA- In Fedora all functionalities of the repository are ac-cessible through a SOAP or REST based web serviceinterface- Moreover Fedora is Open Source and has a strongcommunity behind it

Name of Solution DSpaceLink httpwwwdspaceorgAccess Open sourceFunctionality Storage of documentsLimitations with respect to TAS3 Not all functions available over web service interfaceRelated Requirements Partially D12-86Name of Solution CDSwareLink httpcdswarecernchAccess Open sourceFunctionality Storage of documentsLimitations with respect to TAS3 Not all functions available over web service interfaceRelated Requirements Partially D12-86Name of Solution EPrintsLink httpwwweprintsorgAccess Open sourceFunctionality Storage of documentsLimitations with respect to TAS3 Not all functions available over web service interfaceRelated Requirements Partially D12-86

Name of Solution SaturnLink httpsaturnportalnottinghamacukAccess University of Nottingham authorised access only as the

system contains live student data Proprietary systemdesigned built and maintained in house

Functionality University of Nottingham student records systemLimitations with respect to TAS3 - Not yet web-service enabled

- Closed internal system - As this is live student datawe cannot create test accounts for the project

Related Requirements Used for authentication of student ID within our demon-strator also used to establish eligibility for scheme Al-lows access to module information to show which mod-ules the student is studying

Justification of Selection Source of student data as held by the institution

Name of Solution ePARS (electronic Personal and Academic RecordSystem)

Link httpseparsnottinghamacuksharedhtmaboutasp

Access University of Nottingham system

Version 20

Functionality Designed to support tutorials and student personal de-velopment

Limitations with respect to TAS3 Used as a proxy for SaturnRelated Requirements Takes regular data dumps of data from the live Saturn

system and has a facility to create test accounts withdummy data so can act as a proxy for Saturn in thedemonstrator

Justification of Selection Allows access to Saturn data without having to accessSaturn direct which we would not be allowed to do fordemonstration purposes

Name of Solution OPUSLink httpfossulsteracukprojectsopusAccess Open source we have an instance installed on our de-

velopment serverFunctionality Placement co-ordination packageLimitations with respect to TAS3 Local implementations only can have multiple in-

stances in a systemRelated Requirements The software is specially designed for placement man-

agement and will be linked into the ePortfolio to aidstudents in the vacancy discovery process and skillsmatching scenarios

Justification of Selection Open source customisable

Name of Solution MaharaLink httpmaharaorgAccess Open sourceFunctionality ePortfolio systemLimitations with respect to TAS3 Designed primarily as a learning ePortfolio but a lot of

work is being done by the community to support use forwork placements

Related Requirements Learner-owned system needs to be hosted but is out-side the university or placement provider control Thelearner can control which information others can seeWeb access

Justification of Selection Many ePortfolio systems are available there are over80 in use in the UK at the moment but not all are freeand not all are web-based Many remain under institu-tional control This system is open source we are incontact with the developers through other project workand there is ongoing development to support use forwork placements so there is a strong community of in-terest

Name of Solution PebblePadLink httpwwwpebblepadcoukAccess ProprietaryFunctionality Personal ePortfolio systemLimitations with respect to TAS3 Designed primarily to support learningRelated Requirements Learner-owned system which interfaces to the ePortfo-

lio and letrsquos learners control which information otherscan see

Version 20

Justification of Selection Web-based learner-controlled system We have agood relationship with the company through otherproject work The system supports exports in a varietyof standards including UK-LEAP and IMS ePortfolioFurthermore we are likely to be able to access demon-strator candidates who have established ePortfolios us-ing the system and offer a rich source of demonstratordata

Name of Solution Kenteq Competent WEB applicationLink httptestcompetentkenteqnlAccess The application is property of KenteqFunctionality Competent provides functionality to complete adminis-

tration services test employment candidates and gen-erate reports

Limitations with respect to TAS3 Competent does not support the full (complete) em-ployability process

Related Requirements See prior D12 chapter WP09 APL demo 8 - 14Justification of Selection Most applications that support (parts of) employability

processes are embedded in software for internal HRprocesses Competent supports the APL and profilematching process as such independently from the or-ganisation or individual who applies for an employabil-ity service There is no other off-the-shelve applicationavailable who supports employability processes Theapplication of the employability provider is outside theTAS3 infrastructure but within the scope of the TAS3

demonstrator where it is necessary as application tosupport and exchange data for the demonstrator sce-narios D14 13 APL and 14 Mass layoff The ap-plication is in English and Dutch language what is anadvantage for the NL demonstrator

Name of Solution PILS Patient Information Location ServiceLink httpwwwcustodixcomAccess Proprietary Custodix Software Available for the

demonstrators can be customized for the demonstra-tors

Functionality Front-end for looking up (distributed search) and dis-playing medical information from different medicalrepositories

Limitations with respect to TAS3 No known limitations at this point in timeRelated Requirements Providing a front-end for data retrieval in the eHealth

scenarios of D14 and D91Justification of Selection Fully working solution completely under the control of

one of the partners (Custodix) which means that thesolution can easily be customized to fit into the pilotsNext to PILS an XACML driven medical record repos-itory is available Together they form a complete sys-tem for access to distributed medical information withdynamic policy based access control The completesystem is a good benchmark for evaluating the addedvalue of TAS3

Version 20

Name of Solution Personal Health RecordLink No link availableAccess Depending on official choice (presumed to be propri-

etary)Functionality Personal data store for managing personal medical in-

formation (ie patient controlled repository)Limitations with respect to TAS3 Originally Medisoft was providing the Orca system

However they left the project early as they felt theycould no longer provide the required software The ad-ministrative complexity of this event has delayed officialappointment of a new PHR subcontractor (a candidateis available though)

Related Requirements User centric (ie with user supplied data) medicalrepository A place where a patient can manage hisown data The PHR concentrates data from a vari-ety of sources (from accredited professionals to carersand the patient himself) and is an important element fortesting trust based components

Justification of Selection The current candidate is selected by the pilot end-usersthemselves for their pathology (patient organization)

Name of Solution WS-GuardLink httpplasticisticnritwikitoolsAccess Open source (GPLv3)Functionality WS-Guard provides a prototype implementation of a

framework augmenting the registration phase of a ser-vice within a registry with a testing phase Registrationis then guaranteed only if the service passes the test-ing phase

Limitations with respect to TAS3 The conformance validation is based on behaviouralmodels in the form of Service State Machines (SSM)Within TAS3 we intend to verify service compliancebased on the manifested policy Furthermore there isno support to the notions of identity and roles

Related Requirements D12-109 D12-101 D12-102Justification of Selection WS-Guard is developed by CNR as a result of research

in related areas There is no comparative tool perform-ing the same functionalities

Name of Solution ZXIDLink httpwwwzxidorgAccess Open source (Apache License 20)

Version 20

Functionality ZXID aims at full stack implementation of all feder-ated identity management and identity web servicesprotocols Initial goal is supporting SP role followedby ID-WSF WSC and IdP roles Provides user au-thentication and SSO using SAMLv2 Specifically 1SAML 20 SSO SP role and XACML PEP for Apacheas modauthsaml2 SAML 20 SSO SP role as programming toolkit forC C++ Java C PHP and Perl3 SAML 20 SSO IdP role4 XACML PEP as programming toolkit for C C++Java C PHP and Perl5 ID-WSF WSC role as programming toolkit for CC++ Java C PHP and Perl6 ID-WSF WSP role as programming toolkit for CC++ Java C PHP and Perl7 Discovery client as programming toolkit for C C++Java C PHP and Perl8 Discovery registration as programming toolkit for CC++ Java C PHP and Perl9 Discovery service10 People Service Client as programming toolkit for CC++ Java C PHP and Perl11 People Service

Related Requirements D12-108 D12-102Justification of Selection Nonexclusive choice Written by SAML ID-WSF and

XACML insider Well interopped SAML 20 and ID-WSF 20 certified in its commercial (Symlabs) incar-nation Developed by a TAS3 contributor so ensuresgood support Also selected by the architecture team

Name of Solution TAXILink httpwww1isticnritERITAXItaxi_

indexhtmlAccess Open source (GPLv2)Functionality TAXI is a tool for the systematic generation of XML in-

stances The TAXI methodology is largely inspired tothe well-known Category Partition which provides astepwise intuitive approach to functional testing as fol-lows identify the relevant input parameters define theenvironment conditions combine their significant val-ues into an effective test suite

Limitations with respect to TAS3 Cannot deal with negative tests and fuzz tests More-over it does not currently address handling of accesspolicies eg XACML

Related Requirements D12-101 D12-102Justification of Selection TAXI is developed by CNR as a result of research in

related areas There is no comparative tool performingthe same functionalities

Name of Solution Eye-Tracker TobiiLink httpwwwtobiicom

Version 20

Access Proprietary Accessible by University of Zaragoza atWalqa (a technological park of reference in Spain)

Functionality Tools for identifying what participants look at during thecourse of a usability-accessibility test Other offeringsexist in the market but Tobbi solutions can be consid-ered as the leader in this field

Limitations with respect to TAS3 Any usability and accessibility analysis is limited if it isnot completed with indicators that allow accurate mea-surement of how easy it is to manage the applicationthat is perceived usability by end-users

Related Requirements D12-106 D12-107 (but this tool does not fully com-ply with the non-technical perspective of this require-ment)

Justification of Selection

Name of Solution ClickTracks WebTrendsLink httpwwwclicktrackscom http

wwwwebtrendscomAccess ProprietaryFunctionality Specific software packages for tracking the software

userrsquos behaviour especially when the software is im-plemented over web protocols Others free or low-costsolutions such Google Analytics dont offer the samelevel of functionalities

Limitations with respect to TAS3 This tools do not allow us to assess the levels of usabil-ity or accessibility so that it is not possible to determinewhether the software user is satisfied or not

Related Requirements D12-106 D12-107 (but these tools are insufficientto fully comply with the non-technical perspective of thisrequirement)

Name of Solution Structural Modeling (EQS PLS SPSS)Link httpwwwmvsoftcom httpwwwspss

comAccess ProprietaryFunctionality Analyze causal relationships among multiple latent

variables Others packages such as LISREL or AMOSoffer similar functionalities but the research group hasbeen working with EQS PLS and SPSS for severalyears In addition other techniques such as linear re-gression or cluster analysis do not allow to analyzerelationships among latent variables or to include avariable that plays a double role (independent as welldependent) which is possible to conduct in structuralmodeling

Limitations with respect to TAS3 NARelated Requirements D12-104 D12-105 D12-106 (these tools will help

to analyze relationships among variables that will serveto determine the main precursors of trust and servicequality on end-users mind)

Justification of Selection University of Zaragoza has the access to these specificstatistical packages

Version 20

Name of Solution JiraLink httpwwwatlassiancomsoftwarejiraAccess ProprietaryFunctionality Flexible web based bug tracking issue tracking task

tracking and project management software solutionused for open source and enterprise projects

Limitations with respect to TAS3 Cost complexityRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

Name of Solution Concurrent Versions System CVSLink httpenwikipediaorgwikiConcurrent_

Versions_SystemAccess Open sourceFunctionality Basic file repository with good revision controlLimitations with respect to TAS3 File-based optimised for textRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution Subversion SVNLink httpsubversiontigrisorgAccess OpenSourceFunctionality Basic file repository with good revision controlLimitations with respect to TAS3 File-basedRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution MediaWikiLink httpwwwmediawikiorgAccess OpenSourceFunctionality Wiki package for document and file managementLimitations with respect to TAS3 Complexity needs a databaseRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution DokuWikiLink httpwwwdokuwikiorgAccess OpenSourceFunctionality Wiki package for document and file managementLimitations with respect to TAS3

Related Requirements D12-121 D12-122 D12-123 (D12-124 D12-125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Name of Solution ConfluenceLink httpwwwatlassiancomsoftware

confluenceAccess ProprietaryFunctionality Confluence is a simple powerful wiki that lets you cre-

ate and share pages documents and rich content withyour team

Limitations with respect to TAS3 Cost complexity needs Java and a databaseRelated Requirements D12-121 D12-122 D12-123 (D12-124 D12-

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

Name of Solution RedmineLink httpwwwredmineorgAccess OpenSourceFunctionality Redmine is a flexible project management web appli-

cation Written using Ruby on Rails framework it iscross-platform and cross-database

Limitations with respect to TAS3 Assumes a particular work flow model and dedicatedresources for response and dispatch

Related Requirements D12-122 D12-123 (D12-124 D12-125 D12-126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution TracLink httptracedgewallorgAccess OpenSourceFunctionality Trac is an enhanced wiki and issue tracking system for

software development projects Trac uses a minimal-istic approach to web-based software project manage-ment Our mission is to help developers write greatsoftware while staying out of the way Trac should im-pose as little as possible on a teamrsquos established de-velopment process and policies

Limitations with respect to TAS3 Complex and heavyweightRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution BugZillaLink httpwwwbugzillaorgAccess OpenSourceFunctionality Bugzilla is server software designed to help you man-

age software developmentLimitations with respect to TAS3 Complex and heavyweightRelated Requirements D12-123 (D12-124 D12-126 D12-1223 D12-

1224 D12-1230)

Name of Solution GITLink httpgit-scmcomAccess OpenSourceFunctionality Git is a free and open source distributed version con-

trol system designed to handle everything from small tovery large projects with speed and efficiency

Limitations with respect to TAS3 Possibly immatureRelated Requirements D12-122 D12-123 (D12-124 D12-125 D12-

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Name of Solution HudsonLink httpshudsondevjavanetAccess OpenSource

Version 20

Functionality Hudson monitors executions of repeated jobs such asbuilding a software project or jobs run by cron

Limitations with respect to TAS3 Possibly heavyweight biased to JavaRelated Requirements D12-127 (D12-1211 D12-1215)

Name of Solution ActiveCollabLink httpwwwactivecollabcomAccess ProprietaryFunctionality ActiveCollab is a project management and collabora-

tion tool that you can set up on your own website Havean area where you can collaborate with your teamclients and contractors and keep projects on track whileretaining full control over access permissions and yourdata

Limitations with respect to TAS3 Implies a work process that relies on dedicated re-sources

Name of Solution NagiosLink httpwwwnagiosorgAccess OpenSourceFunctionality Scalable resourcenetwork monitor frameworkLimitations with respect to TAS3

Related Requirements D12-127 (D12-1211 D12-1215)Justification of Selection

Name of Solution Semantic MediaWiki SMWLink httpenwikipediaorgwikiSemantic_

MediaWikiAccess OpenSourceFunctionality SMW allows for annotating semantic data within wiki

pages thus turning a wiki that incorporates the exten-sion into a semantic wiki

Limitations with respect to TAS3 Possibly over the top complex for what developers doRelated Requirements D12-121 D12-122 D12-123 (D12-124 D12-

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Name of Solution OntoPrise OntoStudioLink httpwwwontoprisedeenhome

productsontostudioAccess ProprietaryOpenSource dual licensedFunctionality Extensions of SMW for production purposes support-

ing ontology development and integrationLimitations with respect to TAS3 Possibly cost lack of dedicated resources to use it

Version 20

Name of Solution DOGMA Studio WorkbenchLinkAccess Although the solution is open-source the software is

located on a web server with restricted accessFunctionality It allows the elicitation and visualisation of DOGMA in-

spired ontologiesLimitations with respect to TAS3

Related Requirements D12-223Justification of Selection This is the only tool that supports DOGMA inspired on-

tology

Version 20

E Inter-WP Requirements Interactions (First Itera-tion)E1 Interactions of WP2

Source Re-quirement

D12-223

supports D12-312 D12-314depends onabstractsimplementssimilar toNote

This requirement will be fulfilled by WPs WP2

E2 Interactions of WP3

Source Re-quirement

D12-31

supports D12-223 D12-55depends on D12-63abstractsimplementssimilar toNote

D12-32

supports D12-55 D12-612 D12-91depends on D12-62abstractsimplements D12-83similar toNote Partially implements D12-612

D12-33

supports D12-610depends onabstractsimplementssimilar toNote

D12-34

supports D12-912depends onabstractsimplementssimilar toNote I would have expected some requirement(s) that specif-

ically target(s) the ID management infrastructure thatD21 describes in so much detail but I cant find one(would be a depends on)

D12-35

supports

Version 20

depends on D12-713abstractsimplements D12-723 D12- 94similar toNote

This requirement will be fulfilled by WPs WP3 WP7

D12-36

supportsdepends on D1-713abstractsimplements D12-723 D12-94similar toNote

D12-37

supportsdepends on D12-713abstractsimplements D12-71similar toNote

D12-39

supportsdepends on D12-103abstractsimplementssimilar toNote

D12-311

supports D12-214depends onabstracts D12-77implements D12-726similar to D12-85 D12-96Note

D12-312

supports D12-108depends onabstractsimplementssimilar to D12-214 D12-47 D12-223Note

D12-313

supports D12-55depends on D12-66abstractsimplementssimilar toNote

D12-314

supportsdepends onabstractsimplements D12-223 D12-108similar toNote

D12-15

supportsdepends on D12-49 D12-51

Version 20

abstractsimplementssimilar toNote

Source Re-quirement

D12-41

supports D12-29 D12-220 D12-77 D12-726 D12-85D12-86 D12-92 D12-96 D12-97 D12-912D12-913 D12-98 D12-99

depends on D12-218 D12-219abstracts D12-311implementssimilar toNote

D12-42

supports D12-78 D12-716 D12-718 D12-727 D12-916D12-1227

depends onabstracts D12-34implementssimilar toNote

D12-43

supports D12-21 D12-25 D12-26 D12-37 D12-121D12-105

depends onabstractsimplementssimilar toNote

D12-44

supports D12-211 D12-212 D12-214 D12-71 D12-76D12-210 D12-215 D12-222 D12-33 D12-37D12-714 D12-721 D12-724 D12-725 D12-94D12-95 D12-911 D12-916 D12-917

depends on D12-218 D12-219abstracts D12-217 D12-312 D12-73 D12-910implementssimilar toNote

D12-45

supports D12-211 D12-212 D12-214 D12-29 D12-210D12-220 D12-37 D12-312 D12-315 D12-910D12-916 D12-922

depends on D12-218 D12-219abstracts D12-221 D12-724implementssimilar toNote

D12-46

supports D12-310 D12-722

Version 20

depends on D12-218 D12-219abstractsimplementssimilar toNote

D12-47

supports D12-25D12-210 D12-211 D12-212depends onabstracts D12-314implementssimilar toNote

D12-48

supports D12-211 D12-212 D12-210 D12-213 D12-33D12-93 D12-97 D12-914 D12-106

D12-49

supports D12-51 D12-210 D12-53 D12-54depends onabstractsimplementssimilar toNote

E4 Interactions of WP 5

Source Re-quirement

D12-51

supports D12-104depends onabstractsimplementssimilar toNote As part of the overall authorization framework this re-

quirement also support requirements on authorization(D12-220 D12-311 D12-45 D12-66 D12-612D12-76 D12-91 D12-94)

D12-55

supportsdepends on D12-31 and D12-313abstractsimplementssimilar toNote Business process management (WP3) should provide

support for and check inclusion of a feedback formwhich enables the user to give feedback on the cur-rent process For the demonstrator use cases it will beaddressed by WP9 in the trust dashboard

D12-56

supports

Version 20

depends on D12-712 D12-715abstractsimplements D12-713similar toNote The credential based trust management (CTM) service

will require credential handling For credentials ex-pressing trust relationships finding credentials is partof the CTM service design

D12-59

supports D12-212 D12-213 D12-43 D12-84 D12-85D12-96

depends onabstractsimplements D12-713similar toNote The credential based trust management (CTM) service

D12-510

supportsdepends onabstractsimplementssimilar to D12-73 D12-34 D12-912Note Implementing D12-73 in such a way that D12-34 is

achieved will also satisfy this requirement D12-912 isa reformulation of the same requirement (with differentjustification)

WP 6 consists of the legal requirements and contractual framework Both of these topics are horizontal andcrosscutting impacting or being impacted by every aspect of the project To that end WP6 Interactions willbe set forth in a more text-based fashion at the level of the interaction with the WP rather than at the specificrequirement level though attempts will be made to call out those requirements that have special relationshipswith legal requirements or the contractual framework

We mentioned in Section 44 that WP6 entails three kind of requirements intake and qualification basic legalrequirements that emanate from the EU Data Protection Directive and requirements related to the contractand policy frameworks In the course of mapping interactions they will be described as the Intake LegalRequirement and Contract Framework sections respectively

WP2 ndash Architecture As a central element of TAS3 the architecture is perhaps most closely in-tertwined with both the legal requirements and contract framework Oneof the innovative approaches of TAS3 was the development of technologypolicy and contractlegal in collaboration and there has been significant in-teraction between the architecture team in addressing legal requirements(D12-221 -222) and in functions such as authentication (D12-217) log-ging access control and audit (D12-218 The Important relationshipsalso exist as related to the contract framework where contract and re-quired policies support security (D12-27 -216) oversightaccountability(D12-215) implementation of TAS3 (D12-29) and functions such aslimits on disclosure (D12-220)

Version 20

WP3 ndash Business ProcessModeling

Business processes are related to legal requirements because in theirmodeling they must operate within the confines of the legal requirementsIssues like treating PIIIdentity management ((D12-34) Access controland role management (D12-36-36 -310) and user controls (D12-311)They are likewise supported and constrained by contractual requirementsthat impose obligations The most important one is the requirement tohave access to a privacy policy (D12-314) Contract framework canalso help support functions like special circumstances and error recov-ery (D12-39) and delegation (D12-37)

WP4 ndash Secure and Trust-worthy Processing

By its very subject matter WP4 is tasked to give effect to many of thelegal requirements Concepts of user control (D12-41) confidentiali-typseudonymity (D12-42 contributes) and proofcompliance functions(D12-45-46) are all essential to privacy The latter two are also essen-tial elements that both support and are supported by the contract frame-work One of the reasons why the collaborative approach is so needed isbecause of these interactions where a requirements is both supported byand supporting an aspect of the contract framework

WP5 ndash Flexible Trust Man-agement Framework

Legal and contract framework interaction with WP5 may be more in termsof how some elements of WP5 give effect to requirements through mech-anisms as well as how those mechanisms may be enabled For instancelegal requirements of user control will be given effect through (D12-51-53) the need for trust policies and management is essential to users mak-ing informed choices and setting appropriate controls The ability to usereputation and other feedback information (D12-54-55) will need to beenabled by contracts binding the reputation services ((D12-511)

WP7 ndash Privacy Authoriza-tion Infrastructure

In many ways WP7 provides the technical mediation of privacy which isinformed by privacy requirements and supported by the contract frame-work to bind service providers to the processestechnical elementsAmong the more important legal requirements support by WP7 are col-lection limitation ((D12-75) user control (D12-77) pseudonymity (D12-716) data minimization (D12-718) and consent (D12-726) WP7 alsoprovides functions in support of the contract framework which are like-wise supported by provisions of the contract framework most notablyoversight by tracking delegations (D12-71 -714) authorizations (D12-76 -723) and preventing collusion (D12-78 -718)

WP8 ndash Uniform Interface WP8 is mostly providing technical functionalityspecification which maybe related to legal requirements and contract framework in elements suchas end user interface ((D12-84) user control ((D12-85) and access toboth legacy (D12-82) and repository data (D12-86)

WP9 ndash Demonstrators The demonstrators are the place where we test the contract frameworkand assess mechanisms of compliance with legal requirements as suchthey are part of the iterative development process of the operation ofthe contract framework and the completeness and usability of the legalrequirements Essential elements of both legal requirements and con-tract framework such as user control (D12-92 -96) audit (D12-95)Access (D12-97-98) data minimization (D12-916) and security (D12-94-913) are all specified and brought to life in the demonstrators

Version 20

WP10 ndash Quality WP10 is an important element in testingdemonstrating compliance andoversight This role is important to help assure that legal requirementsare followed and to enable better visibility of possible contract frameworkviolations or issues Some aspects of the testing process may also beuseful in judging the capacity for compliance as part of the intake pro-cess The WP requirements specify important compliance elements in-cluding ongoing testing (D12-101) Detection of service failures and er-rors (D12-102-103) and propagation of service provider characteristics(D12-108)

WP12 ndash Integration WP12 plays an important project role to help assure that the elementsof TAS3 work in unison From both the legal requirements and contractframework perspective these are import functions as both require thatTAS3 be able to provide a cohesive trust and security architecture withappropriate end-to end controls and functionality Integration of programcomponents is an obvious necessity

Source Re-quirement

D12-71

D12-73

supports D12-510 D12-94 D12-916 D12-917 D12-918D12-919 D12-920 D12-921

D12-76

supports D12-220 D12-45 D12-91 D12-94 D12-910D12-922

D12-77

supports D12-311 D12-41 D12-85 D12-92 D12-96D12-98 D12-912

D12-79

supports D12-310depends onabstracts

Version 20

implementssimilar toNote

D12-712

D12-713

D12-715

D12-717

D12-719

supports D12-36 D12-37 D12-313depends onabstractsimplementssimilar toNote

D12-720

D12-722

D12-724

Version 20

D12-727

Source Re-quirement

D12-81

supports D12-23 D12-24 D12-25 D12-26 D12-29 D12-213 D12-92 D12-911 D12-914 D12-312 D12-314 D12-718

depends on D12-221 D12-223 D12-72 D12-71 D12-73D12-76 D12-714

abstractsimplementssimilar toNote ADPEP - gateway

This requirement will be fulfilled by WPs WP8 WP2 WP7 WP4

D12-82

supports D12-97 D12-718depends onabstractsimplementssimilar toNote Legacy databases

D12-83

supports D12-312 D12-314depends on D12-31 D12-32 D12-33 D12-36 D12-35

D12-37 D12-38 D12-39 D12-311abstractsimplementssimilar toNote Business process

D12-84

supports D12-97 D12-911 D12-914 D12-915 D12-916depends on D12-31 D12-32 D12-33abstractsimplementssimilar toNote Generic client

D12-85

supports D12-96 D12-99 D12-711depends on D12-719 D12-720abstractsimplementssimilar toNote policymanagement

This requirement will be fulfilled by WPs WP8 WP7 WP5

Version 20

D12-86

supports D12-97 D12-916depends onabstractsimplementssimilar toNote repository

Source Re-quirement

D12-91

supports D12-220 D12-223 D12-1214 D12-1215depends on D12-21 D12-22 D12-25 D12-36 D12-37

D12-38 D12-310 D12-612 D12-711 D12-81D12-82

abstracts D12-24 D12-86implements D12-66 D12-108 D12-109similar toNote

D12-92

abstracts D12-214 D12-311 D12-77 D12-711implementssimilar to D12-85Note

D12-93

supports D12-212D12-43 D12-612depends on D12-510 D12-76 D12-712 D12-714 D127-15abstracts D12-28 D12-210 D12-213 D12-48 D12-73implements D12-73 D12-106 D12-107similar to D12-75Note

D12-94

supports D12-210 D12-214 D12-215 D12-220 D12-34D12-43 D12-68D12-612 D12-726 D12-104D12-105 D12-1213

depends on D12-218 D12-219 D12-61 D12-723abstracts D12-36 D12-74implements D12-27 D12-1215similar to D12-510 D12-73 D12-76Note

D12-95

supports D12-215 D12-222 D12-41 D12-44 D12-69D12-610 D12-721 D12-725 D12-102 D12-124 D12-1210 D12-1213 D12-1215

depends on D12-34abstractsimplements D12-217similar to D12-724Note

Version 20

D12-96

depends on D12-48 D12-77 D12-1213abstracts D12-210 D12-314 D12-711implements D12-85similar toNote

D12-97

supports D12-211 D12-215 D12-43 D12-610 d12-721depends on D12-28 D12-219 D12-62 D12-63 D12-612

D12-73 D12-76 D12-82abstractsimplementssimilar to D12-68 D12-86Note

D12-98

depends on D12-213 D12-217 D12-311 D12-315 D12-41D12-510 D12-76 D12-716 D12-724

abstractsimplementssimilar to D12-222 D12-68Note

D12-99

supports D12-311 D12-41 D12-66depends on D12-29 D12-210 D12-211 D12-214 D12-48abstracts D12-315 D12-67 D12-85implements D12-726similar to D12-77 D12-711Note

D12-910

supports D12-210 D12-212 D12-311 D12-314depends onabstractsimplements D12-213 D12-214 D12-106 D12-107similar to D12-33 D12-48 D12-84Note

This requirement will be fulfilled by WPs WP04WP8 WP10

D12-911

depends on D12-34 D12-612 D12-716 D12-82 D12-86abstracts D12-1227 D12-1228implements D12-29similar to D12-223Note

D12-912

supports D12-210 D12-211 D12-213 D12-217 D12-220 D12-36 D12-41 D12-66 D12-68 D12-72D12-73 D12-76 D12-722 D12-726

depends on D12-218 D12-219abstracts D12-74 D12-75 D12-716implements D12-510similar to

Version 20

NoteThis requirement will be fulfilled by WPs WP7

D12-913

supports D12-214 D12-220 D12-46 D12-612 D12-73D12-726

depends on D12-43 D12-74 D12-75 D12-715 D12-716abstracts D12-27 D12-216 D12-310implementssimilar to D12-218 D12-219 D12-76Note

D12-914

supports D12-24 D12-210depends onabstractsimplementssimilar toNote May contradict D12-211

D12-915

supports D12-22 D12-210 D12105 D12-106depends onabstractsimplementssimilar toNote

This requirement will be fulfilled by WPs W2 WP4 WP8 WP10

D12-916

supports D12-215 D12-216 D12-63 D12-612depends on D12-82 D12-86abstracts D12-64implementssimilar toNote

Source Re-quirement

D12-101

supports D12-216depends on D12-21 D12-22 D12-25 D12-26 D12-121

D12-1211abstracts D12-129 D12-1214implementssimilar toNote

D12-102

supports D12-216depends on D12-223 D12-56 D12-74 D12-76 D12-1211abstracts D12-1214implementssimilar toNote

D12-103

supports D12-1214 D12-1215depends on D12-223abstractsimplements

Version 20

similar toNote

D12-108

supports D12-47 D12-1214 D12-1215depends on D12-223abstractsimplements D12-1213 D12-1217similar toNote

D12-109

supports D12-216depends on D12-21 D12-22abstractsimplements D12-1213 D12-1214 D12-1215similar toNote

D12-104

D12-94 D12-96abstractsimplementssimilar toNote

D12-105

supportsdepends on D12-29 D12-43 D12-94 D12-915abstractsimplementssimilar toNote

D12-106

supports D12-210 D12-211 D12-212 D12-213 D12-48D12-915

depends onabstracts D12-93 D12-910implementssimilar toNote

D12-107

supportsdepends on D12-28 D12-83 D12-84 D12-85abstracts D12-93 D12-910implementssimilar toNote

Version 20

F Inter-WP Requirements Interaction (Second It-eration)

The following is a depiction of the interaction between the technical requirements after the second iterationof this analysis with all the updated requirements The inconsistencies are combed out of this list which ispresented in the DOT notation which is interpreted as follows

The number of ldquoRequirement 1rdquo also indicates the WP that authored the interaction

F1 Interactions of WP3

ldquoD12-31rdquorarr ldquoD12-55rdquo [label = ldquoIrdquo]ldquoD12-31rdquorarr ldquoD12-63rdquo [label = ldquoDrdquo]

ldquoD12-32rdquorarr ldquoD12-55rdquo [label = ldquoIrdquo]ldquoD12-32rdquorarr ldquoD12-612rdquo [label = ldquoSrdquo]ldquoD12-32rdquorarr ldquoD12-91rdquo [label = ldquoSrdquo]ldquoD12-32rdquorarr ldquoD12-62rdquo [label = ldquoDrdquo]ldquoD12-32rdquorarr ldquoD12-83rdquo [label = ldquoIrdquo]ldquoD12-32rdquorarr ldquoD12-612rdquo [label = rdquoPart Irdquo]

ldquoD12-33rdquorarr ldquoD12-610rdquo [label = ldquoSrdquo]

ldquoD12-35rdquorarr ldquoD12-713rdquo [label = ldquoDrdquo]ldquoD12-35rdquorarr ldquoD12-723rdquo [label = ldquoIrdquo]ldquoD12-35rdquorarr ldquoD12-729rdquo [label = ldquoDrdquo]ldquoD12-36rdquorarr ldquoD12-713rdquo [label = ldquoDrdquo]ldquoD12-36rdquorarr ldquoD12-723rdquo [label = ldquoIrdquo]

ldquoD12-37rdquorarr ldquoD12-713rdquo [label = ldquoDrdquo]ldquoD12-37rdquorarr ldquoD12-71rdquo [label = ldquoIrdquo]

ldquoD12-39rdquorarr ldquoD12-103rdquo [label = ldquoDrdquo]

ldquoD12-311rdquorarr ldquoD12-214rdquo [label = ldquoSrdquo]ldquoD12-311rdquorarr ldquoD12-77rdquo [label = ldquoArdquo]ldquoD12-311rdquorarr ldquoD12-726rdquo [label = ldquoIrdquo]

ldquoD12-313rdquorarr ldquoD12-55rdquo [label = ldquoSrdquo]ldquoD12-313rdquorarr ldquoD12-66rdquo [label = ldquoDrdquo]

ldquoD12-314rdquorarr ldquoD12-223rdquo [label = ldquoIrdquo]ldquoD12-314rdquorarr ldquoD12-108rdquo [label = ldquoIrdquo]

ldquoD12-315rdquorarr ldquoD12-49rdquo [label = ldquoDrdquo]ldquoD12-315rdquorarr ldquoD12-51rdquo [label = ldquoDrdquo]

Version 20

ldquoD12-41rdquorarr ldquoD12-29rdquo [label = ldquoSrdquo] ldquoD12-41rdquorarr ldquoD12-220rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-77rdquo [label = ldquoIrdquo]ldquoD12-41rdquorarr ldquoD12-726rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-86rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-92rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-96rdquo [label = ldquoArdquo]ldquoD12-41rdquorarr ldquoD12-98rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-99rdquo [label = ldquoSrdquo]ldquoD12-41rdquorarr ldquoD12-218rdquo [label = ldquoDrdquo]ldquoD12-41rdquorarr ldquoD12-219rdquo [label = ldquoDrdquo]ldquoD12-41rdquorarr ldquoD12-31rdquo [label = ldquoArdquo]

ldquoD12-42rdquorarr ldquoD12-78rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-716rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-718rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-727rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-916rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-1227rdquo [label = ldquoSrdquo]ldquoD12-42rdquorarr ldquoD12-34rdquo [label = ldquoArdquo]

ldquoD12-43rdquorarr ldquoD12-21rdquo [label = ldquoSrdquo]ldquoD12-43rdquorarr ldquoD12-25rdquo [label = ldquoSrdquo]ldquoD12-43rdquorarr ldquoD12-26rdquo [label = ldquoSrdquo]ldquoD12-43rdquorarr ldquoD12-37rdquo [label = ldquoSrdquo]ldquoD12-43rdquorarr ldquoD12-121rdquo [label = ldquoSrdquo]

ldquoD12-44rdquorarr ldquoD12-211rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-212rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-214rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-71rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-76rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-210rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-215rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-222rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-33rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-37rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-714rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-721rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-724rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-725rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-95rdquo [label = ldquoArdquo]ldquoD12-44rdquorarr ldquoD12-916rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-917rdquo [label = ldquoSrdquo]ldquoD12-44rdquorarr ldquoD12-218rdquo [label = ldquoDrdquo]ldquoD12-44rdquorarr ldquoD12-219rdquo [label = ldquoDrdquo]ldquoD12-44rdquorarr ldquoD12-217rdquo [label = ldquoArdquo]ldquoD12-44rdquorarr ldquoD12-312rdquo [label = ldquoArdquo]ldquoD12-44rdquorarr ldquoD12-73rdquo [label = ldquoArdquo]

ldquoD12-45rdquorarr ldquoD12-211rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-212rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-214rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-29rdquo [label = ldquoSrdquo]

Version 20

ldquoD12-45rdquorarr ldquoD12-210rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-220rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-37rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-312rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-315rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-916rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarr ldquoD12-922rdquo [label = ldquoSrdquo]ldquoD12-45rdquorarrldquoD12-218rdquo [label = ldquoDrdquo]ldquoD12-45rdquorarr ldquoD12-219rdquo [label = ldquoDrdquo]ldquoD12-45rdquorarr ldquoD12-221rdquo [label = ldquoArdquo]ldquoD12-45rdquorarr ldquoD12-724rdquo [label = ldquoArdquo]

ldquoD12-46rdquorarr ldquoD12-310rdquo [label = ldquoSrdquo]ldquoD12-46rdquorarr ldquoD12-218rdquo [label = ldquoDrdquo]ldquoD12-46rdquorarr ldquoD12-219rdquo [label = ldquoDrdquo]

ldquoD12-47rdquorarr ldquoD12-25rdquo [label = ldquoSrdquo]ldquoD12-47rdquorarr ldquoD12-210rdquo [label = ldquoSrdquo]ldquoD12-47rdquorarr ldquoD12-211rdquo [label = ldquoSrdquo]ldquoD12-47rdquorarr ldquoD12-212rdquo [label = ldquoSrdquo]ldquoD12-47rdquorarr ldquoD12-314rdquo [label = ldquoArdquo]

ldquoD12-48rdquorarr ldquoD12-211rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-212rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-210rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-213rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-33rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-93rdquo [label = ldquoSrdquo]ldquoD12-48rdquorarr ldquoD12-914rdquo [label = ldquoSrdquo]

ldquoD12-51rdquorarr ldquoD12-921rdquo [label = ldquoSrdquo]ldquoD12-51rdquorarr ldquoD12-922rdquo [label = ldquoSrdquo]ldquoD12-54rdquorarr ldquoD12-1011rdquo [label = ldquoSrdquo]ldquoD12-55rdquorarr ldquoD12-31rdquo [label = ldquoDrdquo]ldquoD12-55rdquorarr ldquoD12-313rdquo [label = ldquoDrdquo]

ldquoD12-56rdquorarr ldquoD12-712rdquo [label = ldquoDrdquo]ldquoD12-56rdquorarr ldquoD12-715rdquo [label = ldquoDrdquo]ldquoD12-56rdquorarr ldquoD12-713rdquo [label = ldquoDrdquo]

ldquoD12-59rdquorarr ldquoD12-212rdquo [label = ldquoSrdquo]ldquoD12-59rdquorarr ldquoD12-213rdquo [label = ldquoSrdquo]ldquoD12-59rdquorarr ldquoD12-43rdquo [label = ldquoSrdquo]ldquoD12-59rdquorarr ldquoD12-84rdquo [label = ldquoSrdquo]ldquoD12-59rdquorarr ldquoD12-96rdquo [label = ldquoSrdquo]ldquoD12-59rdquorarr ldquoD12-713rdquo [label = ldquoIrdquo]

Version 20

ldquoD12-510rdquorarr ldquoD12-73rdquo [label = ldquoIrdquo]

ldquoD12-71rdquorarr ldquoD12-37rdquo [label = ldquoArdquo]

ldquoD12-73rdquorarr ldquoD12-510rdquo [label=ldquoArdquo]ldquoD12-73rdquorarr ldquoD12-916rdquo [label=ldquoSrdquo]ldquoD12-73rdquorarr ldquoD12-917rdquo [label=ldquoSrdquo]ldquoD12-73rdquorarr ldquoD12-918rdquo [label=ldquoSrdquo]ldquoD12-73rdquorarr ldquoD12-919rdquo [label=ldquoSrdquo]ldquoD12-73rdquorarr ldquoD12-920rdquo [label=ldquoSrdquo]ldquoD12-73rdquorarr ldquoD12-921rdquo [label=ldquoSrdquo]

ldquoD12-76rdquorarr ldquoD12-220rdquo [label=ldquoSrdquo]ldquoD12-76rdquorarr ldquoD12-45rdquo [label=ldquoSrdquo]ldquoD12-76rdquorarr ldquoD12-91rdquo [label=ldquoSrdquo]ldquoD12-76rdquorarr ldquoD12-922rdquo [label=ldquoSrdquo]ldquoD12-76rdquorarr ldquoD12-923rdquo [label=ldquoArdquo]

ldquoD12-77rdquorarr ldquoD12-311rdquo [label=ldquoSrdquo]ldquoD12-77rdquorarr ldquoD12-41rdquo [label=ldquoArdquo]ldquoD12-77rdquorarr ldquoD12-92rdquo [label=ldquoSrdquo]ldquoD12-77rdquorarr ldquoD12-96rdquo [label=ldquoArdquo]ldquoD12-77rdquorarr ldquoD12-98rdquo [label=ldquoSrdquo]ldquoD12-77rdquorarr ldquoD12-912rdquo [label=ldquoSrdquo]

ldquoD12-79rdquorarr ldquoD12-310rdquo [label=ldquoSrdquo]

ldquoD12-711rdquorarr ldquoD12-917rdquo [label=ldquoArdquo]

ldquoD12-712rdquorarr ldquoD12-56rdquo [label=ldquoSrdquo]ldquoD12-712rdquorarr ldquoD12-93rdquo [label=ldquoSrdquo]

ldquoD12-719rdquorarr ldquoD12-36rdquo [label=ldquoSrdquo]ldquoD12-719rdquorarr ldquoD12-37rdquo [label=ldquoSrdquo]ldquoD12-719rdquorarr ldquoD12-313rdquo [label=ldquoSrdquo]

Version 20

ldquoD12-81rdquorarr ldquoD12-23rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-24rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-25rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-26rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-29rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-213rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-92rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-914rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-312rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-314rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-718rdquo [label=ldquoSrdquo]ldquoD12-81rdquorarr ldquoD12-221rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-223rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-72rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-71rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-73rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-76rdquo [label=ldquoDrdquo]ldquoD12-81rdquorarr ldquoD12-714rdquo [label=ldquoDrdquo]

ldquoD12-83rdquorarr ldquoD12-312rdquo [label=ldquoSrdquo]ldquoD12-83rdquorarr ldquoD12-314rdquo [label=ldquoSrdquo]ldquoD12-83rdquorarr ldquoD12-31rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-32rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-33rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-36rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-35rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-37rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-38rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-39rdquo [label=ldquoDrdquo]ldquoD12-83rdquorarr ldquoD12-311rdquo [label=ldquoDrdquo]

ldquoD12-84rdquorarr ldquoD12-914rdquo [label=ldquoSrdquo]ldquoD12-84rdquorarr ldquoD12-916rdquo [label=ldquoSrdquo]ldquoD12-84rdquorarr ldquoD12-31rdquo [label=ldquoDrdquo]ldquoD12-84rdquorarr ldquoD12-32rdquo [label=ldquoDrdquo]ldquoD12-84rdquorarr ldquoD12-33rdquo [label=ldquoDrdquo]

ldquoD12-91rdquorarr ldquoD12-220rdquo [label = ldquoSrdquo]ldquoD12-91rdquorarr ldquoD12-223rdquo [label = ldquoSrdquo]ldquoD12-91rdquorarr ldquoD12-214rdquo [label = ldquoSrdquo]ldquoD12-91rdquorarr ldquoD12-215rdquo [label = ldquoSrdquo]ldquoD12-91rdquorarr ldquoD12-36rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-37rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-38rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-310rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-21rdquo [label = ldquoDrdquo]

Version 20

ldquoD12-91rdquorarr ldquoD12-22rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-25rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-612rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-711rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-81rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-82rdquo [label = ldquoDrdquo]ldquoD12-91rdquorarr ldquoD12-24rdquo [label =ldquoArdquo]ldquoD12-91rdquorarr ldquoD12-86rdquo [label =ldquoArdquo]ldquoD12-91rdquorarr ldquoD12-66rdquo [label=ldquoIrdquo]ldquoD12-91rdquorarr ldquoD12-108rdquo [label=ldquoIrdquo]ldquoD12-91rdquorarr ldquoD12-109rdquo [label=ldquoIrdquo]

ldquoD12-92rdquorarr ldquoD12-215rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-220rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-36rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-44rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-45rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-63rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-66rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-76rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-726rdquo [label=ldquoSrdquo]ldquoD12-92rdquorarr ldquoD12-211rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-212rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-314rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-41rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-48rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-59rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-1213rdquo [label =ldquoDrdquo]ldquoD12-92rdquorarr ldquoD12-214rdquo [label=ldquoArdquo]ldquoD12-92rdquorarr ldquoD12-311rdquo [label=ldquoArdquo]ldquoD12-92rdquorarr ldquoD12-77rdquo [label=ldquoArdquo]ldquoD12-92rdquorarr ldquoD12-711rdquo [label=ldquoArdquo]

ldquoD12-93rdquorarr ldquoD12-212rdquo [label=ldquoSrdquo]ldquoD12-93rdquorarr ldquoD12-43rdquo [label=ldquoSrdquo]ldquoD12-93rdquorarr ldquoD12-612rdquo [label=ldquoSrdquo]ldquoD12-93rdquorarr ldquoD12-73rdquo [label=ldquoIrdquo]

ldquoD12-95rdquorarrldquoD12-215rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-222rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-44rdquo [label=ldquoIrdquo]ldquoD12-95rdquorarrldquoD12-69rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-610rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-721rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-725rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-102rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-124rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-1210rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-1213rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-1215rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-34rdquo [label=ldquoSrdquo]ldquoD12-95rdquorarrldquoD12-217rdquo [label=ldquoIrdquo]

ldquoD12-96rdquorarrldquoD12-211rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-214rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-220rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-41rdquo [label=ldquoIrdquo]

Version 20

ldquoD12-96rdquorarrldquoD12-44rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-45rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-64rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-66rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-71rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-723rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-1215rdquo [label=ldquoSrdquo]ldquoD12-96rdquorarrldquoD12-48rdquo [label=ldquoDrdquo]ldquoD12-96rdquorarrldquoD12-77rdquo [label=ldquoIrdquo]ldquoD12-96rdquorarrldquoD12-1213rdquo [label=ldquoDrdquo]ldquoD12-96rdquorarrldquoD12-210rdquo [label=ldquoArdquo]ldquoD12-96rdquorarrldquoD12-314rdquo [label=ldquoArdquo]ldquoD12-96rdquorarrldquoD12-711rdquo [label=ldquoArdquo]

ldquoD12-98rdquorarrldquoD12-210rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-211rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-220rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-43rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-55rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-66rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-69rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-610rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-46rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-728rdquo [label=ldquoSrdquo]ldquoD12-98rdquorarrldquoD12-213rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-217rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-311rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-315rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-41rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-510rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-76rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-716rdquo [label=ldquoDrdquo]ldquoD12-98rdquorarrldquoD12-724rdquo [label=ldquoDrdquo]

ldquoD12-99rdquorarrldquoD12-311rdquo [label=ldquoSrdquo]ldquoD12-99rdquorarrldquoD12-41rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-66rdquo [label=ldquoSrdquo]

ldquoD12-99rdquorarrldquoD12-29rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-210rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-211rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-214rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-48rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-728rdquo [label=ldquoDrdquo]ldquoD12-99rdquorarrldquoD12-315rdquo [label=ldquoArdquo]ldquoD12-99rdquorarrldquoD12-67rdquo [label=ldquoArdquo]ldquoD12-99rdquorarrldquoD12-726rdquo [label=ldquoIrdquo]

ldquoD12-912rdquorarrldquoD12-210rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-211rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-213rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-217rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-220rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-36rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-66rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-68rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-72rdquo [label=ldquoSrdquo]

Version 20

ldquoD12-912rdquorarrldquoD12-73rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-76rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-46rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-726rdquo [label=ldquoSrdquo]ldquoD12-912rdquorarrldquoD12-218rdquo [label=ldquoDrdquo]ldquoD12-912rdquorarrldquoD12-219rdquo [label=ldquoDrdquo]ldquoD12-912rdquorarrldquoD12-74rdquo [label=ldquoArdquo]ldquoD12-912rdquorarrldquoD12-75rdquo [label=ldquoArdquo]ldquoD12-912rdquorarrldquoD12-716rdquo [label=ldquoArdquo]ldquoD12-912rdquorarrldquoD12-510rdquo [label=ldquoIrdquo]

ldquoD12-914rdquorarrldquoD12-24rdquo [label=ldquoSrdquo]ldquoD12-914rdquorarrldquoD12-210rdquo [label=ldquoSrdquo]ldquoD12-914rdquorarrldquoD12-211rdquo [label=rdquoCrdquo]

ldquoD12-916rdquorarrldquoD12-215rdquo [label=ldquoSrdquo]ldquoD12-916rdquorarrldquoD12-216rdquo [label=ldquoSrdquo]ldquoD12-916rdquorarrldquoD12-63rdquo [label=ldquoSrdquo]ldquoD12-916rdquorarrldquoD12-612rdquo [label=ldquoSrdquo]ldquoD12-916rdquorarrldquoD12-82rdquo [label=ldquoDrdquo]ldquoD12-916rdquorarrldquoD12-86rdquo [label=ldquoDrdquo]ldquoD12-916rdquorarrldquoD12-64rdquo [label=ldquoArdquo]ldquoD12-916rdquorarrldquoD12-216rdquo [label=ldquoSrdquo]

ldquoD12-101rdquorarrldquoD12-21rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-22rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-25rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-26rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-121rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-1211rdquo [label=ldquoDrdquo]ldquoD12-101rdquorarrldquoD12-129rdquo [label=ldquoArdquo]ldquoD12-101rdquorarrldquoD12-1214rdquo [label=ldquoArdquo]ldquoD12-102rdquorarrldquoD12-216rdquo [label=ldquoSrdquo]ldquoD12-102rdquorarrldquoD12-223rdquo [label=ldquoDrdquo]ldquoD12-102rdquorarrldquoD12-56rdquo [label=ldquoDrdquo]ldquoD12-102rdquorarrldquoD12-74 rdquo [label=ldquoDrdquo]ldquoD12-102rdquorarrldquoD12-76rdquo [label=ldquoDrdquo]ldquoD12-102rdquorarrldquoD12-1211rdquo [label=ldquoDrdquo]ldquoD12-102rdquorarrldquoD12-1214rdquo [label=ldquoArdquo]

ldquoD12-103rdquorarrldquoD12-1214rdquo [label=ldquoSrdquo]ldquoD12-103rdquorarrldquoD12-1215rdquo [label=ldquoSrdquo]ldquoD12-103rdquorarrldquoD12-223rdquo [label=ldquoDrdquo]

ldquoD12-108rdquorarrldquoD12-47rdquo [label=ldquoSrdquo]ldquoD12-108rdquorarrldquoD12-1214rdquo [label=ldquoSrdquo]ldquoD12-108rdquorarrldquoD12-1215rdquo [label=ldquoSrdquo]ldquoD12-108rdquorarrldquoD12-223rdquo [label=ldquoDrdquo]ldquoD12-108rdquorarrldquoD12-1213rdquo [label=ldquoIrdquo]ldquoD12-108rdquorarrldquoD12-1217rdquo [label=ldquoIrdquo]

ldquoD12-109rdquorarrldquoD12-216rdquo [label=ldquoSrdquo]

Version 20

ldquoD12-109rdquorarrldquoD12-21rdquo [label=ldquoDrdquo]ldquoD12-109rdquorarrldquoD12-22rdquo [label=ldquoDrdquo]ldquoD12-109rdquorarrldquoD12-1213rdquo [label=ldquoIrdquo]ldquoD12-109rdquorarrldquoD12-1214rdquo [label=ldquoIrdquo]ldquoD12-109rdquorarrldquoD12-1215rdquo [label=ldquoIrdquo]

Version 20

Executive Summary

Introduction

Scope and Objectives
Gap Analysis
Requirements Elaboration
Interaction Analysis
Inner WP Requirements Interaction (I1)
Inter-WP Requirements Interaction (I2)
Requirements interaction with Architecture (I3 and I4)
Reiteration of Inter-WP Requirements Interaction (I5)
Interaction of Legal and Technical Requirements (I6 and I7)
Validation of Requirements with the Architecture (I8 and I9)
Structure of the Document
I Deliverable 12 Requirements Assessment Report
Objectives of TAS3 revisited
Objectives of WP2
Objectives of WP3
Objectives of WP4
Objectives of WP5
Objectives of WP6
Objectives of WP7
Objectives of WP8
Objectives of WP9
Objectives of WP10
Objectives of WP12
Requirements interaction in TAS3 Work Packages
Requirements Interaction in WP3
Requirements Interaction in WP 12
Inter-Work Package Technical Requirements Interactions
Similarity Analysis
Inconsistency Analysis
Legal and Technical Requirements Interaction Analysis
Interaction Analysis of New Legal Requirements
Mapping of Legal Requirements to Architecture
Mapping Global Requirements to the TAS3 Architecture
Mapping WP Requirements to the TAS3 Architecture
Gaps
Requirements fulfilled by existing solutions
Existing solutions considered and selected by WP 3 7 and 10 (CNR)
Existing solutions considered and selected by WP 4 and 5
Existing solutions considered and selected by WP 8
Existing solutions considered and selected by WP 10 (UNIZAR)
Existing solutions considered and selected by WP 2 (VUB)
Requirements that call for new solutions
Activities of WP2
Activities of WP3
Activities of WP4
Activities of WP5
Activities of WP6
Activities of WP7
Activities of WP8
Activities of WP9
Activities of WP10
Activities of WP12
Conclusion
Bibliography
II Deliverable 12 Supporting Documents
Requirements Assessment Templates
Template 1 for Gap Analysis and Requirements Elaboration
Template 2 for Inter-WP interactions
Template 3 for Requirements Updates
Updates to Requirements of TAS3
New Requirements of TAS3
Edited Requirements of TAS3
Deleted Requirements of TAS3
Requirements of TAS3
General Requirements of TAS3
Requirements of WP2
Requirements of WP3
Requirements of WP4
Requirements of WP5
Requirements of WP6
Requirements of WP7
Requirements of WP8
Requirements of WP9
Requirements of WP10
Existing Solutions
Inter-WP Requirements Interactions (First Iteration)
Interactions of WP2
Interactions of WP3
Interactions of WP4
Interactions of WP 5
Inter-WP Requirements Interaction (Second Iteration)
Interactions of WP3
Interactions of WP4
Interactions of WP5
Interactions of WP7
Interactions of WP8
Interactions of WP9
Interactions of WP10

The TAS3 Consortium

Nr Participant name Country Participant short name Participant role1 KU Leuven BE KUL Coordinator2 Synergetics BE SYN Project Manager3 University of Kent UK KENT Partner4 University of Karlsruhe BE KARL Partner5 Technische Universiteit

EindhovenNL TUE Partner

6 CNRISTI IT CNR Partner7 University of Koblenz-

LandauDE UNIKOLD Partner

8 Vrije Universiteit Brussel BE VUB Partner9 University of Zaragoza ES UNIZAR Partner10 University of Nottingham UK NOT Partner11 SAP Research DE SAP Partner12 Eifel FR EIF Partner13 Intalio FR INT Partner14 Risaris IR RIS Partner15 Kenteq BE KETQ Partner16 Oracle UK ORACLE Partner17 Custodix BE CUS Partner18 Medisoft NL MEDI Partner

Contributors

Version 20

Table of Contents

2 INTRODUCTION 11

22 GAP ANALYSIS 12

Version 20

81 GAPS 99

Version 20

11 CONCLUSION 116

BIBLIOGRAPHY 117

Version 20

Keyword List

Version 20

22 Gap Analysis

Version 20

I2 I5 (inter WP)

I1 (inner WP)

Version 20

SourceRequire-ment

InteractionType

Target Requirements

D12-6X

Version 20

Part I

Version 20

WP3 35

312313

WP7 WP10

Version 20

5251 D

Version 20

611 612S

Version 20

720719

725724

Version 20

WP8WP4

Version 20

UNIZAR

108102

107 106

121 1214

1211 1210

12301229

12281227 D

Version 20

Source Re-quirement

D12-61

Source Re-quirement

D12-62

Source Re-quirement

Version 20

D12-63D12-631D12-632D12-633

D12-64

D12-66D12-661D12-662D12-663D12-664D12-665D12-666

D12-67

D12-68

Version 20

D12-69D12-670D12-672

D12-610

D12-6101

D12-6102

Version 20

D12-611

D12-613

D12-614

D12-615

Version 20

Source Re-quirement

D12-616

D12-77

D12-617

D12-618D12-6181D12-61823

Source Re-quirement

D12-619

Version 20

D12-620

D12-621D12-622

D12-623

D12-624

D12-6241

Version 20

D12-625D12-6251D12-6252D12-6253

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-630D12-6301

Version 20

Source Re-quirement

D12-631

D12-6321

D12-633D12-634

D12-635

D12-636D12-6361D12-6362D12-6363D12-6364D12-6365

Version 20

D12-637

D12-6371

D12-6372

D12-6373

D12-6374D12-6376

Version 20

D12-6375

D12-6377

Source Re-quirement

D12-638

Version 20

D12-639

D12-640

D12-641

D12-642

D12-643

Version 20

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

Version 20

Source Re-quirement

D12-658

D12-663D12-664D12-6641D12-6642D12-6643

D12-665

D12-666

D12-667D12-6681D12-6682

Version 20

D12-668

D12-669

D12-671

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Version 20

D12-675

D12-676

D12-677D12-6771D12-6772D12-678

D12-679

Version 20

Source Re-quirement

D12-680

D12-727

D12-681

D12-682

D12-683

Version 20

D12-684

D12-685

D12-6851

Source Re-quirement

D12-686

D12-916

D12-67D12-6871

Version 20

D12-688D12-6881D12-6882

Source Re-quirement

D12-69D12-670D12-672

Source Re-quirement

D12-616

D12-77

Version 20

Source Re-quirement

D12-618D12-6181D12-61823

Source Re-quirement

D12-624

Source Re-quirement

D12-625D12-6251D12-6252D12-6253

Version 20

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-6321

Source Re-quirement

D12-6371

Version 20

Source Re-quirement

D12-6377

Source Re-quirement

D12-639

Source Re-quirement

D12-641

Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

is fulfilled by

Version 20

Source Re-quirement

D12-658

Source Re-quirement

D12-665

Version 20

Source Re-quirement

D12-667D12-6681D12-6682

Source Re-quirement

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Source Re-quirement

D12-675

Version 20

Source Re-quirement

D12-680

D12-727

Source Re-quirement

D12-682

Source Re-quirement

D12-6851

Version 20

Source Re-quirement

D12-686

D12-916

Source Re-quirement

D12-67D12-6871

Version 20

D12-21-FeasImp

D12-22-FeasDep

WP2 WP12WP8

architecture)

Version 20

D12-23-BMs

D12-24-MultiVendor

WP2 TAS3

D12-25-Platform

D12-26-Lang

D12-27-Safe

D12-28-Avail

Version 20

D12-29-Correct

WP10 WP8WP9 WP12WP2

D12-211-Transp

D12-212-Compr

WP10 WP2WP3

Version 20

D12-213-Easy

WP10 WP8WP9

D12-214-Priv

D12-215-Resp

D12-216-Mitigate

D12-217-AuditUntamp

D12-218-AnCredi

Version 20

D12-219-AzCredi

D12-220-Az

D12-221-DataProtLaw

D12-222-GovtAccess

WP2 WP7WP6

D12-223-SemIOP

Version 20

D12-224-NoPanopt

D12-31-BPMTools

WP3 WP2WP10

D12-33-Dash

Version 20

D12-34-UID

D12-35-TaskAssign

D12-36-CoordAz

D12-37-Deleg

Version 20

D12-39-BPRecover

D12-311-UPAPD

D12-312-SPManifest

D12-313-BPAdapt

Version 20

D12-315-SecPreserve

WP3 WP8WP2

D12-41-EnfUCPol

D12-42-BPPrivacy

D12-43-SecDemo

WP11 WP9WP12

D12-44-CourtProof

D12-45-ComplyPolicy

WP7 WP2WP10

Version 20

D12-46-BrkGlass

D12-47-PolicyDisco

D12-54-RepuFB

D12-510-UID

D12-512-TrustRank

D12-61-IntakePers

D12-62-IntakeOrg

WP2 WP3WP10

Version 20

D12-64-Min

WP2 WP3WP9

D12-65-Purpose

D12-66-Consent

D12-67-Reconsent

D12-68-UAc

D12-69-Complaint

D12-610-Redress

Version 20

D12-611-Confid

D12-612-Sec

D12-613-Contract

D12-614-Compat

D12-615-MinPolicy

D12-616-Bound

D12-617-TechBind

D12-71-Deleg

Version 20

D12-72-RoleSig

D12-74-MultiCred

D12-75-Min

D12-77-UPA

D12-78-NoColl

Version 20

D12-79-Revoc

D12-710-Target

D12-711-PolMerge

D12-712-CredStepUp

D12-713-CredDisco

D12-714-Sub

D12-715-PushCred

D12-716-Nym

WP2 WP4WP7

D12-717-Increm

D12-718-Seq

Version 20

D12-719-DynaUpd

WP8 WP12WP2

D12-720-PADeleg

D12-721-Safe

D12-727-Separate

D12-728-Audit

D12-729-RoleMap

D12-86-UAc

D12-91-SecData

Version 20

D12-92-UPA

D12-93-SSO

D12-95-Trail

D12-96-UPADetail

D12-97-UAc

D12-98-UAudit

D12-99-UPADyn

Version 20

D12-912-UID

D12-917-PolicyComb

D12-918-Journal

D12-919-Integ

D12-920-Confid

D12-921-AnLvl

Version 20

D12-922-TrustEst

WP6 WP5WP2

D12-923-Min

WP3 WP7WP2

D12-924-UPADyn

Version 20

WP2 WP10WP5

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

D12-121-Grok

D12-122-DokuAc

D12-123-WorkLoad

D12-124-Escalate

D12-125-DokuCVS

WP12 WP13WP8 WP9

D12-126-ProjComm

D12-127-CompChk

WP12 WP8WP9 WP10

D12-128-CtlEnv

Version 20

D12-129-MadTest

WP10 WP12WP8 WP9

D12-1210-MultiEnv

D12-1211-KickStart

D12-1212-SubInst

WP8 WP9WP12

D12-1213-Vfy

D12-1214-Case

D12-1215-Valid

D12-1216-OnlineTst

D12-1217-Doku

WP8 WP9WP7 WP2

D12-1218-ExtDoku

WP12 ZXIDetc

Version 20

D12-1220-Train

D12-1221-ChgMgt

WP12 WP8WP9 WP13

D12-1222-Plan

WP8 WP9WP7 external

D12-1223-BugTraq

D12-1224-RelRepo

D12-1225-IfCat

WP12 WP2WP8 WP9

D12-1226-RefImpl

D12-1227-ComOnto

D12-1228-AppOnto

D12-1229-MockUp

WP8 WP9WP7 WP12

D12-1230-root

Version 20

81 Gaps

How addressed

D12-310-JITPerm

D12-311-UPAPD

D12-312-SPManifest

D12-512-TrustRank

D12-711-PolMerge

D12-92-UPA

D12-96-UPADetail

Version 20

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

Version 20

bull s5 jBPM

bull s6 PERMIS

bull s9 SAMP PHP

bull s10 ZXID

bull s11 Lasso

bull s12 Authentic

bull s13 WS Guard

bull s14 TAXI

Version 20

bull s20 ORACLE

bull s21 SunXACML

Version 20

bull s23 FEDORA

bull s24 DSpace

bull s25 CDSWare

bull s26 EPrints

bull s27 Saturn

bull s28 ePars

bull s29 OPUS

bull s30 Mahara

bull s31 PebblePad

Version 20

bull s35 EyeTracker

Version 20

D12-35D12-36D12-37D12-38D12-310D12-311

D12-36D12-37

D12-313D12-314D12-315D12-316D12-317

Version 20

D12-52D12-58

Version 20

ties below

Version 20

D12-101D12-102D12-109

D12-104D12-105D12-106D12-107

ndash User test

Version 20

D12-121 D12-122 D12-1219D12-1220

D12-123 D12-124 D12-1221D12-1222D12-1223D12-1224

D12-125 D12-126 D12-1223D12-1224D12-1225

D12-127 D12-128 D12-1210D12-1211D12-1213D12-1214D12-1215D12-1216D12-1226

D12-129D12-1212D12-1217D12-1218D12-1219

Version 20

Part II

Version 20

ReqID D12-918

Version 20

demonstrators

Version 20

Justification

Version 20

Justification

Version 20

hline ReqID D12-45

Version 20

ReqID D12-52

Version 20

trust metrics

Version 20

64 and 63

Version 20

Interaction

Version 20

Interaction

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

1224 D12-1230)

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

tology

Version 20

Source Re-quirement

D12-223

Source Re-quirement

D12-31

D12-32

D12-33

D12-34

D12-35

supports

Version 20

D12-36

D12-37

D12-39

D12-311

D12-312

D12-313

D12-314

D12-15

Version 20

Source Re-quirement

D12-41

D12-42

supports D12-78 D12-716 D12-718 D12-727 D12-916D12-1227

D12-43

supports D12-21 D12-25 D12-26 D12-37 D12-121D12-105

D12-44

D12-45

D12-46

Version 20

D12-47

D12-48

D12-49

Source Re-quirement

D12-51

D12-55

D12-56

supports

Version 20

D12-59

supports D12-212 D12-213 D12-43 D12-84 D12-85D12-96

D12-510

Version 20

Source Re-quirement

D12-71

D12-73

D12-76

supports D12-220 D12-45 D12-91 D12-94 D12-910D12-922

D12-77

D12-79

Version 20

D12-712

D12-713

D12-715

D12-717

D12-719

D12-720

D12-722

D12-724

Version 20

D12-727

Source Re-quirement

D12-81

D12-82

D12-83

D12-84

D12-85

Version 20

D12-86

Source Re-quirement

D12-91

D12-38 D12-310 D12-612 D12-711 D12-81D12-82

D12-92

D12-93

D12-94

D12-95

Version 20

D12-96

D12-97

D12-98

D12-99

D12-910

D12-911

D12-912

Version 20

D12-913

supports D12-214 D12-220 D12-46 D12-612 D12-73D12-726

D12-914

D12-915

D12-916

Source Re-quirement

D12-101

D12-102

D12-103

Version 20

similar toNote

D12-108

D12-109

D12-104

D12-105

D12-106

supports D12-210 D12-211 D12-212 D12-213 D12-48D12-915

D12-107

Version 20

Executive Summary

Introduction

Gap Analysis
Objectives of WP2
Objectives of WP3
Objectives of WP4
Objectives of WP5
Objectives of WP6
Objectives of WP7
Objectives of WP8
Objectives of WP9
Objectives of WP10
Objectives of WP12
Similarity Analysis
Gaps
Activities of WP2
Activities of WP3
Activities of WP4
Activities of WP5
Activities of WP6
Activities of WP7
Activities of WP8
Activities of WP9
Activities of WP10
Activities of WP12
Conclusion
Bibliography
Requirements of WP2
Requirements of WP3
Requirements of WP4
Requirements of WP5
Requirements of WP6
Requirements of WP7
Requirements of WP8
Requirements of WP9
Existing Solutions
Interactions of WP2
Interactions of WP3
Interactions of WP4
Interactions of WP3
Interactions of WP4
Interactions of WP5
Interactions of WP7
Interactions of WP8
Interactions of WP9

Version 20

Table of Contents

2 INTRODUCTION 11

22 GAP ANALYSIS 12

Version 20

81 GAPS 99

Version 20

11 CONCLUSION 116

BIBLIOGRAPHY 117

Version 20

Keyword List

Version 20

22 Gap Analysis

Version 20

I2 I5 (inter WP)

I1 (inner WP)

Version 20

SourceRequire-ment

InteractionType

Target Requirements

D12-6X

Version 20

Part I

Version 20

WP3 35

312313

WP7 WP10

Version 20

5251 D

Version 20

611 612S

Version 20

720719

725724

Version 20

WP8WP4

Version 20

UNIZAR

108102

107 106

121 1214

1211 1210

12301229

12281227 D

Version 20

Source Re-quirement

D12-61

Source Re-quirement

D12-62

Source Re-quirement

Version 20

D12-63D12-631D12-632D12-633

D12-64

D12-66D12-661D12-662D12-663D12-664D12-665D12-666

D12-67

D12-68

Version 20

D12-69D12-670D12-672

D12-610

D12-6101

D12-6102

Version 20

D12-611

D12-613

D12-614

D12-615

Version 20

Source Re-quirement

D12-616

D12-77

D12-617

D12-618D12-6181D12-61823

Source Re-quirement

D12-619

Version 20

D12-620

D12-621D12-622

D12-623

D12-624

D12-6241

Version 20

D12-625D12-6251D12-6252D12-6253

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-630D12-6301

Version 20

Source Re-quirement

D12-631

D12-6321

D12-633D12-634

D12-635

D12-636D12-6361D12-6362D12-6363D12-6364D12-6365

Version 20

D12-637

D12-6371

D12-6372

D12-6373

D12-6374D12-6376

Version 20

D12-6375

D12-6377

Source Re-quirement

D12-638

Version 20

D12-639

D12-640

D12-641

D12-642

D12-643

Version 20

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

Version 20

Source Re-quirement

D12-658

D12-663D12-664D12-6641D12-6642D12-6643

D12-665

D12-666

D12-667D12-6681D12-6682

Version 20

D12-668

D12-669

D12-671

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Version 20

D12-675

D12-676

D12-677D12-6771D12-6772D12-678

D12-679

Version 20

Source Re-quirement

D12-680

D12-727

D12-681

D12-682

D12-683

Version 20

D12-684

D12-685

D12-6851

Source Re-quirement

D12-686

D12-916

D12-67D12-6871

Version 20

D12-688D12-6881D12-6882

Source Re-quirement

D12-69D12-670D12-672

Source Re-quirement

D12-616

D12-77

Version 20

Source Re-quirement

D12-618D12-6181D12-61823

Source Re-quirement

D12-624

Source Re-quirement

D12-625D12-6251D12-6252D12-6253

Version 20

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-6321

Source Re-quirement

D12-6371

Version 20

Source Re-quirement

D12-6377

Source Re-quirement

D12-639

Source Re-quirement

D12-641

Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

is fulfilled by

Version 20

Source Re-quirement

D12-658

Source Re-quirement

D12-665

Version 20

Source Re-quirement

D12-667D12-6681D12-6682

Source Re-quirement

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Source Re-quirement

D12-675

Version 20

Source Re-quirement

D12-680

D12-727

Source Re-quirement

D12-682

Source Re-quirement

D12-6851

Version 20

Source Re-quirement

D12-686

D12-916

Source Re-quirement

D12-67D12-6871

Version 20

D12-21-FeasImp

D12-22-FeasDep

WP2 WP12WP8

architecture)

Version 20

D12-23-BMs

D12-24-MultiVendor

WP2 TAS3

D12-25-Platform

D12-26-Lang

D12-27-Safe

D12-28-Avail

Version 20

D12-29-Correct

WP10 WP8WP9 WP12WP2

D12-211-Transp

D12-212-Compr

WP10 WP2WP3

Version 20

D12-213-Easy

WP10 WP8WP9

D12-214-Priv

D12-215-Resp

D12-216-Mitigate

D12-217-AuditUntamp

D12-218-AnCredi

Version 20

D12-219-AzCredi

D12-220-Az

D12-221-DataProtLaw

D12-222-GovtAccess

WP2 WP7WP6

D12-223-SemIOP

Version 20

D12-224-NoPanopt

D12-31-BPMTools

WP3 WP2WP10

D12-33-Dash

Version 20

D12-34-UID

D12-35-TaskAssign

D12-36-CoordAz

D12-37-Deleg

Version 20

D12-39-BPRecover

D12-311-UPAPD

D12-312-SPManifest

D12-313-BPAdapt

Version 20

D12-315-SecPreserve

WP3 WP8WP2

D12-41-EnfUCPol

D12-42-BPPrivacy

D12-43-SecDemo

WP11 WP9WP12

D12-44-CourtProof

D12-45-ComplyPolicy

WP7 WP2WP10

Version 20

D12-46-BrkGlass

D12-47-PolicyDisco

D12-54-RepuFB

D12-510-UID

D12-512-TrustRank

D12-61-IntakePers

D12-62-IntakeOrg

WP2 WP3WP10

Version 20

D12-64-Min

WP2 WP3WP9

D12-65-Purpose

D12-66-Consent

D12-67-Reconsent

D12-68-UAc

D12-69-Complaint

D12-610-Redress

Version 20

D12-611-Confid

D12-612-Sec

D12-613-Contract

D12-614-Compat

D12-615-MinPolicy

D12-616-Bound

D12-617-TechBind

D12-71-Deleg

Version 20

D12-72-RoleSig

D12-74-MultiCred

D12-75-Min

D12-77-UPA

D12-78-NoColl

Version 20

D12-79-Revoc

D12-710-Target

D12-711-PolMerge

D12-712-CredStepUp

D12-713-CredDisco

D12-714-Sub

D12-715-PushCred

D12-716-Nym

WP2 WP4WP7

D12-717-Increm

D12-718-Seq

Version 20

D12-719-DynaUpd

WP8 WP12WP2

D12-720-PADeleg

D12-721-Safe

D12-727-Separate

D12-728-Audit

D12-729-RoleMap

D12-86-UAc

D12-91-SecData

Version 20

D12-92-UPA

D12-93-SSO

D12-95-Trail

D12-96-UPADetail

D12-97-UAc

D12-98-UAudit

D12-99-UPADyn

Version 20

D12-912-UID

D12-917-PolicyComb

D12-918-Journal

D12-919-Integ

D12-920-Confid

D12-921-AnLvl

Version 20

D12-922-TrustEst

WP6 WP5WP2

D12-923-Min

WP3 WP7WP2

D12-924-UPADyn

Version 20

WP2 WP10WP5

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

D12-121-Grok

D12-122-DokuAc

D12-123-WorkLoad

D12-124-Escalate

D12-125-DokuCVS

WP12 WP13WP8 WP9

D12-126-ProjComm

D12-127-CompChk

WP12 WP8WP9 WP10

D12-128-CtlEnv

Version 20

D12-129-MadTest

WP10 WP12WP8 WP9

D12-1210-MultiEnv

D12-1211-KickStart

D12-1212-SubInst

WP8 WP9WP12

D12-1213-Vfy

D12-1214-Case

D12-1215-Valid

D12-1216-OnlineTst

D12-1217-Doku

WP8 WP9WP7 WP2

D12-1218-ExtDoku

WP12 ZXIDetc

Version 20

D12-1220-Train

D12-1221-ChgMgt

WP12 WP8WP9 WP13

D12-1222-Plan

WP8 WP9WP7 external

D12-1223-BugTraq

D12-1224-RelRepo

D12-1225-IfCat

WP12 WP2WP8 WP9

D12-1226-RefImpl

D12-1227-ComOnto

D12-1228-AppOnto

D12-1229-MockUp

WP8 WP9WP7 WP12

D12-1230-root

Version 20

81 Gaps

How addressed

D12-310-JITPerm

D12-311-UPAPD

D12-312-SPManifest

D12-512-TrustRank

D12-711-PolMerge

D12-92-UPA

D12-96-UPADetail

Version 20

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

Version 20

bull s5 jBPM

bull s6 PERMIS

bull s9 SAMP PHP

bull s10 ZXID

bull s11 Lasso

bull s12 Authentic

bull s13 WS Guard

bull s14 TAXI

Version 20

bull s20 ORACLE

bull s21 SunXACML

Version 20

bull s23 FEDORA

bull s24 DSpace

bull s25 CDSWare

bull s26 EPrints

bull s27 Saturn

bull s28 ePars

bull s29 OPUS

bull s30 Mahara

bull s31 PebblePad

Version 20

bull s35 EyeTracker

Version 20

D12-35D12-36D12-37D12-38D12-310D12-311

D12-36D12-37

D12-313D12-314D12-315D12-316D12-317

Version 20

D12-52D12-58

Version 20

ties below

Version 20

D12-101D12-102D12-109

D12-104D12-105D12-106D12-107

ndash User test

Version 20

D12-121 D12-122 D12-1219D12-1220

D12-123 D12-124 D12-1221D12-1222D12-1223D12-1224

D12-125 D12-126 D12-1223D12-1224D12-1225

D12-127 D12-128 D12-1210D12-1211D12-1213D12-1214D12-1215D12-1216D12-1226

D12-129D12-1212D12-1217D12-1218D12-1219

Version 20

Part II

Version 20

ReqID D12-918

Version 20

demonstrators

Version 20

Justification

Version 20

Justification

Version 20

hline ReqID D12-45

Version 20

ReqID D12-52

Version 20

trust metrics

Version 20

64 and 63

Version 20

Interaction

Version 20

Interaction

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

1224 D12-1230)

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

tology

Version 20

Source Re-quirement

D12-223

Source Re-quirement

D12-31

D12-32

D12-33

D12-34

D12-35

supports

Version 20

D12-36

D12-37

D12-39

D12-311

D12-312

D12-313

D12-314

D12-15

Version 20

Source Re-quirement

D12-41

D12-42

supports D12-78 D12-716 D12-718 D12-727 D12-916D12-1227

D12-43

supports D12-21 D12-25 D12-26 D12-37 D12-121D12-105

D12-44

D12-45

D12-46

Version 20

D12-47

D12-48

D12-49

Source Re-quirement

D12-51

D12-55

D12-56

supports

Version 20

D12-59

supports D12-212 D12-213 D12-43 D12-84 D12-85D12-96

D12-510

Version 20

Source Re-quirement

D12-71

D12-73

D12-76

supports D12-220 D12-45 D12-91 D12-94 D12-910D12-922

D12-77

D12-79

Version 20

D12-712

D12-713

D12-715

D12-717

D12-719

D12-720

D12-722

D12-724

Version 20

D12-727

Source Re-quirement

D12-81

D12-82

D12-83

D12-84

D12-85

Version 20

D12-86

Source Re-quirement

D12-91

D12-38 D12-310 D12-612 D12-711 D12-81D12-82

D12-92

D12-93

D12-94

D12-95

Version 20

D12-96

D12-97

D12-98

D12-99

D12-910

D12-911

D12-912

Version 20

D12-913

supports D12-214 D12-220 D12-46 D12-612 D12-73D12-726

D12-914

D12-915

D12-916

Source Re-quirement

D12-101

D12-102

D12-103

Version 20

similar toNote

D12-108

D12-109

D12-104

D12-105

D12-106

supports D12-210 D12-211 D12-212 D12-213 D12-48D12-915

D12-107

Version 20

Executive Summary

Introduction

Gap Analysis
Objectives of WP2
Objectives of WP3
Objectives of WP4
Objectives of WP5
Objectives of WP6
Objectives of WP7
Objectives of WP8
Objectives of WP9
Objectives of WP10
Objectives of WP12
Similarity Analysis
Gaps
Activities of WP2
Activities of WP3
Activities of WP4
Activities of WP5
Activities of WP6
Activities of WP7
Activities of WP8
Activities of WP9
Activities of WP10
Activities of WP12
Conclusion
Bibliography
Requirements of WP2
Requirements of WP3
Requirements of WP4
Requirements of WP5
Requirements of WP6
Requirements of WP7
Requirements of WP8
Requirements of WP9
Existing Solutions
Interactions of WP2
Interactions of WP3
Interactions of WP4
Interactions of WP3
Interactions of WP4
Interactions of WP5
Interactions of WP7
Interactions of WP8
Interactions of WP9

Table of Contents

2 INTRODUCTION 11

22 GAP ANALYSIS 12

Version 20

81 GAPS 99

Version 20

11 CONCLUSION 116

BIBLIOGRAPHY 117

Version 20

Keyword List

Version 20

22 Gap Analysis

Version 20

I2 I5 (inter WP)

I1 (inner WP)

Version 20

SourceRequire-ment

InteractionType

Target Requirements

D12-6X

Version 20

Part I

Version 20

WP3 35

312313

WP7 WP10

Version 20

5251 D

Version 20

611 612S

Version 20

720719

725724

Version 20

WP8WP4

Version 20

UNIZAR

108102

107 106

121 1214

1211 1210

12301229

12281227 D

Version 20

Source Re-quirement

D12-61

Source Re-quirement

D12-62

Source Re-quirement

Version 20

D12-63D12-631D12-632D12-633

D12-64

D12-66D12-661D12-662D12-663D12-664D12-665D12-666

D12-67

D12-68

Version 20

D12-69D12-670D12-672

D12-610

D12-6101

D12-6102

Version 20

D12-611

D12-613

D12-614

D12-615

Version 20

Source Re-quirement

D12-616

D12-77

D12-617

D12-618D12-6181D12-61823

Source Re-quirement

D12-619

Version 20

D12-620

D12-621D12-622

D12-623

D12-624

D12-6241

Version 20

D12-625D12-6251D12-6252D12-6253

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-630D12-6301

Version 20

Source Re-quirement

D12-631

D12-6321

D12-633D12-634

D12-635

D12-636D12-6361D12-6362D12-6363D12-6364D12-6365

Version 20

D12-637

D12-6371

D12-6372

D12-6373

D12-6374D12-6376

Version 20

D12-6375

D12-6377

Source Re-quirement

D12-638

Version 20

D12-639

D12-640

D12-641

D12-642

D12-643

Version 20

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

Version 20

Source Re-quirement

D12-658

D12-663D12-664D12-6641D12-6642D12-6643

D12-665

D12-666

D12-667D12-6681D12-6682

Version 20

D12-668

D12-669

D12-671

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Version 20

D12-675

D12-676

D12-677D12-6771D12-6772D12-678

D12-679

Version 20

Source Re-quirement

D12-680

D12-727

D12-681

D12-682

D12-683

Version 20

D12-684

D12-685

D12-6851

Source Re-quirement

D12-686

D12-916

D12-67D12-6871

Version 20

D12-688D12-6881D12-6882

Source Re-quirement

D12-69D12-670D12-672

Source Re-quirement

D12-616

D12-77

Version 20

Source Re-quirement

D12-618D12-6181D12-61823

Source Re-quirement

D12-624

Source Re-quirement

D12-625D12-6251D12-6252D12-6253

Version 20

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-6321

Source Re-quirement

D12-6371

Version 20

Source Re-quirement

D12-6377

Source Re-quirement

D12-639

Source Re-quirement

D12-641

Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

is fulfilled by

Version 20

Source Re-quirement

D12-658

Source Re-quirement

D12-665

Version 20

Source Re-quirement

D12-667D12-6681D12-6682

Source Re-quirement

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Source Re-quirement

D12-675

Version 20

Source Re-quirement

D12-680

D12-727

Source Re-quirement

D12-682

Source Re-quirement

D12-6851

Version 20

Source Re-quirement

D12-686

D12-916

Source Re-quirement

D12-67D12-6871

Version 20

D12-21-FeasImp

D12-22-FeasDep

WP2 WP12WP8

architecture)

Version 20

D12-23-BMs

D12-24-MultiVendor

WP2 TAS3

D12-25-Platform

D12-26-Lang

D12-27-Safe

D12-28-Avail

Version 20

D12-29-Correct

WP10 WP8WP9 WP12WP2

D12-211-Transp

D12-212-Compr

WP10 WP2WP3

Version 20

D12-213-Easy

WP10 WP8WP9

D12-214-Priv

D12-215-Resp

D12-216-Mitigate

D12-217-AuditUntamp

D12-218-AnCredi

Version 20

D12-219-AzCredi

D12-220-Az

D12-221-DataProtLaw

D12-222-GovtAccess

WP2 WP7WP6

D12-223-SemIOP

Version 20

D12-224-NoPanopt

D12-31-BPMTools

WP3 WP2WP10

D12-33-Dash

Version 20

D12-34-UID

D12-35-TaskAssign

D12-36-CoordAz

D12-37-Deleg

Version 20

D12-39-BPRecover

D12-311-UPAPD

D12-312-SPManifest

D12-313-BPAdapt

Version 20

D12-315-SecPreserve

WP3 WP8WP2

D12-41-EnfUCPol

D12-42-BPPrivacy

D12-43-SecDemo

WP11 WP9WP12

D12-44-CourtProof

D12-45-ComplyPolicy

WP7 WP2WP10

Version 20

D12-46-BrkGlass

D12-47-PolicyDisco

D12-54-RepuFB

D12-510-UID

D12-512-TrustRank

D12-61-IntakePers

D12-62-IntakeOrg

WP2 WP3WP10

Version 20

D12-64-Min

WP2 WP3WP9

D12-65-Purpose

D12-66-Consent

D12-67-Reconsent

D12-68-UAc

D12-69-Complaint

D12-610-Redress

Version 20

D12-611-Confid

D12-612-Sec

D12-613-Contract

D12-614-Compat

D12-615-MinPolicy

D12-616-Bound

D12-617-TechBind

D12-71-Deleg

Version 20

D12-72-RoleSig

D12-74-MultiCred

D12-75-Min

D12-77-UPA

D12-78-NoColl

Version 20

D12-79-Revoc

D12-710-Target

D12-711-PolMerge

D12-712-CredStepUp

D12-713-CredDisco

D12-714-Sub

D12-715-PushCred

D12-716-Nym

WP2 WP4WP7

D12-717-Increm

D12-718-Seq

Version 20

D12-719-DynaUpd

WP8 WP12WP2

D12-720-PADeleg

D12-721-Safe

D12-727-Separate

D12-728-Audit

D12-729-RoleMap

D12-86-UAc

D12-91-SecData

Version 20

D12-92-UPA

D12-93-SSO

D12-95-Trail

D12-96-UPADetail

D12-97-UAc

D12-98-UAudit

D12-99-UPADyn

Version 20

D12-912-UID

D12-917-PolicyComb

D12-918-Journal

D12-919-Integ

D12-920-Confid

D12-921-AnLvl

Version 20

D12-922-TrustEst

WP6 WP5WP2

D12-923-Min

WP3 WP7WP2

D12-924-UPADyn

Version 20

WP2 WP10WP5

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

D12-121-Grok

D12-122-DokuAc

D12-123-WorkLoad

D12-124-Escalate

D12-125-DokuCVS

WP12 WP13WP8 WP9

D12-126-ProjComm

D12-127-CompChk

WP12 WP8WP9 WP10

D12-128-CtlEnv

Version 20

D12-129-MadTest

WP10 WP12WP8 WP9

D12-1210-MultiEnv

D12-1211-KickStart

D12-1212-SubInst

WP8 WP9WP12

D12-1213-Vfy

D12-1214-Case

D12-1215-Valid

D12-1216-OnlineTst

D12-1217-Doku

WP8 WP9WP7 WP2

D12-1218-ExtDoku

WP12 ZXIDetc

Version 20

D12-1220-Train

D12-1221-ChgMgt

WP12 WP8WP9 WP13

D12-1222-Plan

WP8 WP9WP7 external

D12-1223-BugTraq

D12-1224-RelRepo

D12-1225-IfCat

WP12 WP2WP8 WP9

D12-1226-RefImpl

D12-1227-ComOnto

D12-1228-AppOnto

D12-1229-MockUp

WP8 WP9WP7 WP12

D12-1230-root

Version 20

81 Gaps

How addressed

D12-310-JITPerm

D12-311-UPAPD

D12-312-SPManifest

D12-512-TrustRank

D12-711-PolMerge

D12-92-UPA

D12-96-UPADetail

Version 20

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

Version 20

bull s5 jBPM

bull s6 PERMIS

bull s9 SAMP PHP

bull s10 ZXID

bull s11 Lasso

bull s12 Authentic

bull s13 WS Guard

bull s14 TAXI

Version 20

bull s20 ORACLE

bull s21 SunXACML

Version 20

bull s23 FEDORA

bull s24 DSpace

bull s25 CDSWare

bull s26 EPrints

bull s27 Saturn

bull s28 ePars

bull s29 OPUS

bull s30 Mahara

bull s31 PebblePad

Version 20

bull s35 EyeTracker

Version 20

D12-35D12-36D12-37D12-38D12-310D12-311

D12-36D12-37

D12-313D12-314D12-315D12-316D12-317

Version 20

D12-52D12-58

Version 20

ties below

Version 20

D12-101D12-102D12-109

D12-104D12-105D12-106D12-107

ndash User test

Version 20

D12-121 D12-122 D12-1219D12-1220

D12-123 D12-124 D12-1221D12-1222D12-1223D12-1224

D12-125 D12-126 D12-1223D12-1224D12-1225

D12-127 D12-128 D12-1210D12-1211D12-1213D12-1214D12-1215D12-1216D12-1226

D12-129D12-1212D12-1217D12-1218D12-1219

Version 20

Part II

Version 20

ReqID D12-918

Version 20

demonstrators

Version 20

Justification

Version 20

Justification

Version 20

hline ReqID D12-45

Version 20

ReqID D12-52

Version 20

trust metrics

Version 20

64 and 63

Version 20

Interaction

Version 20

Interaction

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

1224 D12-1230)

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

tology

Version 20

Source Re-quirement

D12-223

Source Re-quirement

D12-31

D12-32

D12-33

D12-34

D12-35

supports

Version 20

D12-36

D12-37

D12-39

D12-311

D12-312

D12-313

D12-314

D12-15

Version 20

Source Re-quirement

D12-41

D12-42

supports D12-78 D12-716 D12-718 D12-727 D12-916D12-1227

D12-43

supports D12-21 D12-25 D12-26 D12-37 D12-121D12-105

D12-44

D12-45

D12-46

Version 20

D12-47

D12-48

D12-49

Source Re-quirement

D12-51

D12-55

D12-56

supports

Version 20

D12-59

supports D12-212 D12-213 D12-43 D12-84 D12-85D12-96

D12-510

Version 20

Source Re-quirement

D12-71

D12-73

D12-76

supports D12-220 D12-45 D12-91 D12-94 D12-910D12-922

D12-77

D12-79

Version 20

D12-712

D12-713

D12-715

D12-717

D12-719

D12-720

D12-722

D12-724

Version 20

D12-727

Source Re-quirement

D12-81

D12-82

D12-83

D12-84

D12-85

Version 20

D12-86

Source Re-quirement

D12-91

D12-38 D12-310 D12-612 D12-711 D12-81D12-82

D12-92

D12-93

D12-94

D12-95

Version 20

D12-96

D12-97

D12-98

D12-99

D12-910

D12-911

D12-912

Version 20

D12-913

supports D12-214 D12-220 D12-46 D12-612 D12-73D12-726

D12-914

D12-915

D12-916

Source Re-quirement

D12-101

D12-102

D12-103

Version 20

similar toNote

D12-108

D12-109

D12-104

D12-105

D12-106

supports D12-210 D12-211 D12-212 D12-213 D12-48D12-915

D12-107

Version 20

Executive Summary

Introduction

Gap Analysis
Objectives of WP2
Objectives of WP3
Objectives of WP4
Objectives of WP5
Objectives of WP6
Objectives of WP7
Objectives of WP8
Objectives of WP9
Objectives of WP10
Objectives of WP12
Similarity Analysis
Gaps
Activities of WP2
Activities of WP3
Activities of WP4
Activities of WP5
Activities of WP6
Activities of WP7
Activities of WP8
Activities of WP9
Activities of WP10
Activities of WP12
Conclusion
Bibliography
Requirements of WP2
Requirements of WP3
Requirements of WP4
Requirements of WP5
Requirements of WP6
Requirements of WP7
Requirements of WP8
Requirements of WP9
Existing Solutions
Interactions of WP2
Interactions of WP3
Interactions of WP4
Interactions of WP3
Interactions of WP4
Interactions of WP5
Interactions of WP7
Interactions of WP8
Interactions of WP9

81 GAPS 99

Version 20

11 CONCLUSION 116

BIBLIOGRAPHY 117

Version 20

Keyword List

Version 20

22 Gap Analysis

Version 20

I2 I5 (inter WP)

I1 (inner WP)

Version 20

SourceRequire-ment

InteractionType

Target Requirements

D12-6X

Version 20

Part I

Version 20

WP3 35

312313

WP7 WP10

Version 20

5251 D

Version 20

611 612S

Version 20

720719

725724

Version 20

WP8WP4

Version 20

UNIZAR

108102

107 106

121 1214

1211 1210

12301229

12281227 D

Version 20

Source Re-quirement

D12-61

Source Re-quirement

D12-62

Source Re-quirement

Version 20

D12-63D12-631D12-632D12-633

D12-64

D12-66D12-661D12-662D12-663D12-664D12-665D12-666

D12-67

D12-68

Version 20

D12-69D12-670D12-672

D12-610

D12-6101

D12-6102

Version 20

D12-611

D12-613

D12-614

D12-615

Version 20

Source Re-quirement

D12-616

D12-77

D12-617

D12-618D12-6181D12-61823

Source Re-quirement

D12-619

Version 20

D12-620

D12-621D12-622

D12-623

D12-624

D12-6241

Version 20

D12-625D12-6251D12-6252D12-6253

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-630D12-6301

Version 20

Source Re-quirement

D12-631

D12-6321

D12-633D12-634

D12-635

D12-636D12-6361D12-6362D12-6363D12-6364D12-6365

Version 20

D12-637

D12-6371

D12-6372

D12-6373

D12-6374D12-6376

Version 20

D12-6375

D12-6377

Source Re-quirement

D12-638

Version 20

D12-639

D12-640

D12-641

D12-642

D12-643

Version 20

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

Version 20

Source Re-quirement

D12-658

D12-663D12-664D12-6641D12-6642D12-6643

D12-665

D12-666

D12-667D12-6681D12-6682

Version 20

D12-668

D12-669

D12-671

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Version 20

D12-675

D12-676

D12-677D12-6771D12-6772D12-678

D12-679

Version 20

Source Re-quirement

D12-680

D12-727

D12-681

D12-682

D12-683

Version 20

D12-684

D12-685

D12-6851

Source Re-quirement

D12-686

D12-916

D12-67D12-6871

Version 20

D12-688D12-6881D12-6882

Source Re-quirement

D12-69D12-670D12-672

Source Re-quirement

D12-616

D12-77

Version 20

Source Re-quirement

D12-618D12-6181D12-61823

Source Re-quirement

D12-624

Source Re-quirement

D12-625D12-6251D12-6252D12-6253

Version 20

Source Re-quirement

D12-626D12-627D12-628D12-629

Source Re-quirement

D12-6321

Source Re-quirement

D12-6371

Version 20

Source Re-quirement

D12-6377

Source Re-quirement

D12-639

Source Re-quirement

D12-641

Source Re-quirement

D12-651D12-652D12-653D12-654D12-655D12-6551D12-6552D12-6553D12-656D12-657D12-659D12-660D12-661D12-662

is fulfilled by

Version 20

Source Re-quirement

D12-658

Source Re-quirement

D12-665

Version 20

Source Re-quirement

D12-667D12-6681D12-6682

Source Re-quirement

D12-673D12-6731D12-6732

D12-215 D12- 44

D12-674

Source Re-quirement

D12-675

Version 20

Source Re-quirement

D12-680

D12-727

Source Re-quirement

D12-682

Source Re-quirement

D12-6851

Version 20

Source Re-quirement

D12-686

D12-916

Source Re-quirement

D12-67D12-6871

Version 20

D12-21-FeasImp

D12-22-FeasDep

WP2 WP12WP8

architecture)

Version 20

D12-23-BMs

D12-24-MultiVendor

WP2 TAS3

D12-25-Platform

D12-26-Lang

D12-27-Safe

D12-28-Avail

Version 20

D12-29-Correct

WP10 WP8WP9 WP12WP2

D12-211-Transp

D12-212-Compr

WP10 WP2WP3

Version 20

D12-213-Easy

WP10 WP8WP9

D12-214-Priv

D12-215-Resp

D12-216-Mitigate

D12-217-AuditUntamp

D12-218-AnCredi

Version 20

D12-219-AzCredi

D12-220-Az

D12-221-DataProtLaw

D12-222-GovtAccess

WP2 WP7WP6

D12-223-SemIOP

Version 20

D12-224-NoPanopt

D12-31-BPMTools

WP3 WP2WP10

D12-33-Dash

Version 20

D12-34-UID

D12-35-TaskAssign

D12-36-CoordAz

D12-37-Deleg

Version 20

D12-39-BPRecover

D12-311-UPAPD

D12-312-SPManifest

D12-313-BPAdapt

Version 20

D12-315-SecPreserve

WP3 WP8WP2

D12-41-EnfUCPol

D12-42-BPPrivacy

D12-43-SecDemo

WP11 WP9WP12

D12-44-CourtProof

D12-45-ComplyPolicy

WP7 WP2WP10

Version 20

D12-46-BrkGlass

D12-47-PolicyDisco

D12-54-RepuFB

D12-510-UID

D12-512-TrustRank

D12-61-IntakePers

D12-62-IntakeOrg

WP2 WP3WP10

Version 20

D12-64-Min

WP2 WP3WP9

D12-65-Purpose

D12-66-Consent

D12-67-Reconsent

D12-68-UAc

D12-69-Complaint

D12-610-Redress

Version 20

D12-611-Confid

D12-612-Sec

D12-613-Contract

D12-614-Compat

D12-615-MinPolicy

D12-616-Bound

D12-617-TechBind

D12-71-Deleg

Version 20

D12-72-RoleSig

D12-74-MultiCred

D12-75-Min

D12-77-UPA

D12-78-NoColl

Version 20

D12-79-Revoc

D12-710-Target

D12-711-PolMerge

D12-712-CredStepUp

D12-713-CredDisco

D12-714-Sub

D12-715-PushCred

D12-716-Nym

WP2 WP4WP7

D12-717-Increm

D12-718-Seq

Version 20

D12-719-DynaUpd

WP8 WP12WP2

D12-720-PADeleg

D12-721-Safe

D12-727-Separate

D12-728-Audit

D12-729-RoleMap

D12-86-UAc

D12-91-SecData

Version 20

D12-92-UPA

D12-93-SSO

D12-95-Trail

D12-96-UPADetail

D12-97-UAc

D12-98-UAudit

D12-99-UPADyn

Version 20

D12-912-UID

D12-917-PolicyComb

D12-918-Journal

D12-919-Integ

D12-920-Confid

D12-921-AnLvl

Version 20

D12-922-TrustEst

WP6 WP5WP2

D12-923-Min

WP3 WP7WP2

D12-924-UPADyn

Version 20

WP2 WP10WP5

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

D12-121-Grok

D12-122-DokuAc

D12-123-WorkLoad

D12-124-Escalate

D12-125-DokuCVS

WP12 WP13WP8 WP9

D12-126-ProjComm

D12-127-CompChk

WP12 WP8WP9 WP10

D12-128-CtlEnv

Version 20

D12-129-MadTest

WP10 WP12WP8 WP9

D12-1210-MultiEnv

D12-1211-KickStart

D12-1212-SubInst

WP8 WP9WP12

D12-1213-Vfy

D12-1214-Case

D12-1215-Valid

D12-1216-OnlineTst

D12-1217-Doku

WP8 WP9WP7 WP2

D12-1218-ExtDoku

WP12 ZXIDetc

Version 20

D12-1220-Train

D12-1221-ChgMgt

WP12 WP8WP9 WP13

D12-1222-Plan

WP8 WP9WP7 external

D12-1223-BugTraq

D12-1224-RelRepo

D12-1225-IfCat

WP12 WP2WP8 WP9

D12-1226-RefImpl

D12-1227-ComOnto

D12-1228-AppOnto

D12-1229-MockUp

WP8 WP9WP7 WP12

D12-1230-root

Version 20

81 Gaps

How addressed

D12-310-JITPerm

D12-311-UPAPD

D12-312-SPManifest

D12-512-TrustRank

D12-711-PolMerge

D12-92-UPA

D12-96-UPADetail

Version 20

D12-1012-ModelIf

D12-1013-ModelAz

WP7 WP10WP2

Version 20

bull s5 jBPM

bull s6 PERMIS

bull s9 SAMP PHP

bull s10 ZXID

bull s11 Lasso

bull s12 Authentic

bull s13 WS Guard

bull s14 TAXI

Version 20

bull s20 ORACLE

bull s21 SunXACML

Version 20

bull s23 FEDORA

bull s24 DSpace

bull s25 CDSWare

bull s26 EPrints

bull s27 Saturn

bull s28 ePars

bull s29 OPUS

bull s30 Mahara

bull s31 PebblePad

Version 20

bull s35 EyeTracker

Version 20

D12-35D12-36D12-37D12-38D12-310D12-311

D12-36D12-37

D12-313D12-314D12-315D12-316D12-317

Version 20

D12-52D12-58

Version 20

ties below

Version 20

D12-101D12-102D12-109

D12-104D12-105D12-106D12-107

ndash User test

Version 20

D12-121 D12-122 D12-1219D12-1220

D12-123 D12-124 D12-1221D12-1222D12-1223D12-1224

D12-125 D12-126 D12-1223D12-1224D12-1225

D12-127 D12-128 D12-1210D12-1211D12-1213D12-1214D12-1215D12-1216D12-1226

D12-129D12-1212D12-1217D12-1218D12-1219

Version 20

Part II

Version 20

ReqID D12-918

Version 20

demonstrators

Version 20

Justification

Version 20

Justification

Version 20

hline ReqID D12-45

Version 20

ReqID D12-52

Version 20

trust metrics

Version 20

64 and 63

Version 20

Interaction

Version 20

Interaction

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

1224 D12-1230)

126 D12-126 D12-1217 D12-1218 D12-1219D12-1221 D12-1224 D12-1225 D12-1230)

Version 20

125 D12-126 D12-126 D12-1217 D12-1218D12-1219 D12-1220 D12-1221 D12-1224D12-1225 D12-1227 D12-1230)

Version 20

tology

Version 20

Source Re-quirement

D12-223

Source Re-quirement

D12-31

D12-32

D12-33

D12-34

D12-35

supports

Version 20

D12-36

D12-37

D12-39

D12-311

D12-312

D12-313

D12-314

D12-15

Version 20

Source Re-quirement

D12-41

D12-42

supports D12-78 D12-716 D12-718 D12-727 D12-916D12-1227

D12-43

supports D12-21 D12-25 D12-26 D12-37 D12-121D12-105

D12-44

D12-45

D12-46

Version 20

D12-47

D12-48

D12-49

Source Re-quirement

D12-51

D12-55

D12-56

supports

Version 20

D12-59

supports D12-212 D12-213 D12-43 D12-84 D12-85D12-96

D12-510

Version 20

Source Re-quirement

D12-71

D12-73

D12-76

supports D12-220 D12-45 D12-91 D12-94 D12-910D12-922

D12-77

D12-79

Version 20

D12-712

D12-713

D12-715

D12-717

D12-719

D12-720

D12-722

D12-724

Version 20

D12-727

Source Re-quirement

D12-81

D12-82

D12-83

D12-84

D12-85

Version 20

D12-86

Source Re-quirement

D12-91

D12-38 D12-310 D12-612 D12-711 D12-81D12-82

D12-92

D12-93

D12-94

D12-95

Version 20

D12-96

D12-97

D12-98

D12-99

D12-910

D12-911

D12-912

Version 20

D12-913

supports D12-214 D12-220 D12-46 D12-612 D12-73D12-726

D12-914

D12-915

D12-916

Source Re-quirement

D12-101

D12-102

D12-103

Version 20

similar toNote

D12-108

D12-109

D12-104

D12-105

D12-106

supports D12-210 D12-211 D12-212 D12-213 D12-48D12-915

D12-107

Version 20

Executive Summary

Introduction

Gap Analysis
Objectives of WP2
Objectives of WP3
Objectives of WP4
Objectives of WP5
Objectives of WP6
Objectives of WP7
Objectives of WP8
Objectives of WP9
Objectives of WP10
Objectives of WP12
Similarity Analysis
Gaps
Activities of WP2
Activities of WP3
Activities of WP4
Activities of WP5
Activities of WP6
Activities of WP7
Activities of WP8
Activities of WP9
Activities of WP10
Activities of WP12
Conclusion
Bibliography
Requirements of WP2
Requirements of WP3
Requirements of WP4
Requirements of WP5
Requirements of WP6
Requirements of WP7
Requirements of WP8
Requirements of WP9
Existing Solutions
Interactions of WP2
Interactions of WP3
Interactions of WP4
Interactions of WP3
Interactions of WP4
Interactions of WP5
Interactions of WP7
Interactions of WP8
Interactions of WP9

SEVENTH FRAMEWORK PROGRAMME Challenge 1 Information …

Documents

Seventh Research Framework Programme (FP7)

SEVENTH FRAMEWORK PROGRAMME THEME 7: Transport …

SEVENTH FRAMEWORK PROGRAMME Research Infrastructures

SEVENTH FRAMEWORK PROGRAMME - Web-COSI

SEVENTH FRAMEWORK PROGRAMME

Seventh Grade Science Framework Overivews

Seventh Framework Programme (FP7)

SEVENTH FRAMEWORK PROGRAMME - SysSec: About

SEVENTH FRAMEWORK PROGRAMME MARIE CURIE...

RTE-7@TAC2010 The Seventh Recognizing Textual Entailment...

SEVENTH FRAMEWORK PROGRAMME Information and …

Seventh Framework Programme Cognitive Systems ......Seventh....

European Commission Seventh Framework programme MODSafe ...

SEVENTH FRAMEWORK PROGRAMME Information & … · Framework....

SEVENTH FRAMEWORK PROGRAMME and new … · SEVENTH...

SEVENTH FRAMEWORK...