1. Marc Santos / Ingo Dahn University Koblenz-Landau, Knowledge Media Institute Koblenz

2. What‘s to come?  The European Integrated Project TAS 3  Main Tas 3 Goals/Challenges  Data Structure  Fedora as central component in TAS 3  Architecture of Tas 3

3. The European Integrated Project TAS 3  TAS 3 : “Trusted Architecture for Securely Shared Services”  Handle person related information  project has started January 1, 2008  We have 4 years to achieve our goals  The Catholic University in Leuven is coordinating the project  Together with Synergetics

4. The European Integrated Project TAS 3  TAS 3 Consortium  18 partners from 8 different countries  SAP Research  Oracle  Synergetics (Belgium)  University of Nottingham  Dr. Angela Smallwood – Director of the University‘s Centre for International ePortfolio Development  University of Kent  David Chadwick -Professor of Information Systems Security and Leader of the Information Systems Security Group  …  University Koblenz-Landau  3 years of experience with Fedora  Repository, that supports different Metada standards from the Elearning area  Fedora is now used as backend DB in 3 projects

5. Tas 3 Goals/Challenges (Fedora related)  “The project will allow users and service providers in the employability and e-Health sectors to manage the lifelong generated personal information of the individuals involved.”  Employability and e-Health as reference sectors to test our prototype architecture  Generic architecture (e-Learning etc.)  Support ‘Sticky policies’  Not DB wide, but for each data item  Fedora helps us  Support for XACML  XACML in a special datastream  Support ‘Break-the-glass’

6. Break the Glass Service  Break-the-Glass service  or “an emergency override procedure”  E.g. healthcare professionals need access to person related data  Data Protection Guard triggers an audit trail service  Logging all actions of the doctor  Afterwards one can control the activities  Strong authentication  A method to grant a person access to data, to which he/she normally has no access to. Policy Decision Point Patient Record 1. (6). Access patient record 2. Denied 8. Granted 3. Break the Glass 4. Enforce Data Protection Policy 5. Granted Audit Trail 7. Retrieve Record Policy Enforcement Point Obligations Service Data Protection Policy Guard

7. Tas 3 Goals/Challenges (Fedora related )  Store person related information in an internal format  Independent from special formats  Support for Multiple Standards/Specifications (e.g. IMS LIP, HR-XML, SICCT)  But in a dynamical way: ‘Dynamical transformation to satisfy different requirements of the specification in use by the receiving party.’  Fedora delivers the solution  Using Disseminators and a XSL transformation web service

8. Data Structure – Specification neutral IMS- LIP HR- XML Use case from the employability sector She‘s applying for a job All her competencies are stored in the IMS-LIP format She grants the personnel director access to her person related data (sticky policy) Now he is allowed to fetch data But he doesn‘t work with IMS-LIP. He needs HR-XML

9. Internal Format – CCTS Core Components  Developed by UN/CEFACT group  A standard motivated by eCommerce  Is part of the ebXML (electronic business)  The suggested data structure is ‚Simple but flexible‘  Objects consist only of name-value pairs and pointers  easy to store in relational Databases  Objects mapped to Fedora objects  Improvement of CCTS by using Fedora‘s Datastreams and Disseminators  Augmented by DC and Sticky Policy  Interrelations between data objects are defined by RDFS (Resource Description Framework schema)  Again – Fedora helps us Integrated Triplestore based on Kowari or MPTStore  planning to migrate to MULGARA

10. Functions of Fedora in Tas 3  Disseminators to realize different dynamically generated formats  Internal format based on “Core Components”  transformed into the required format  Each Fedora object has un unlimited number of Datastreams --- perfect for  ‘Sticky Policies’  to add Metadata – DC or …  Triplestore to reflect Semantics  Shielding Legacy Systems behind Fedora  A lot of data in legacy systems  integrate these legacy systems – Fedora as gateway layer on top  Idea from Risaris (Ireland)  Challenging task

11. Architecture of Tas 3 (initial approach) Simplistic diagram Main players Trust- and Security Services This is the heart of the architecture But has no relations to Fedora Service Requester realized 1. iteration as browser then as Smart Client Service Provider With Fedora as it‘s core component

13. Transformation Services Based on XSL, since most of the docs stored are based on XML XSLT processor Fedora provides it as web service Aggregation Service Web of distributed Fedora instances Person related data may be also distributed Search services Fedora API-A Basic Search Triplestore search – RI web service interface „Security Services“ Not doing the authentication or authorization work Secure the line (SSL), Secure SOAP messages using WS- Security Send some information to the Trust and Security Services : Credentials, Request for data, Policies Receives: YES or NO

14. API-M Management tasks addDatastream, addDisseminator, ingest API-A Fetching data, searching data listDatastreams, findObjects Fedora as gateway for legacy systems Realized by Disseminators using web services from Risaris to query in legacy databases Transaction component Not sure if we need it… Multiuser system So we have to think about transactions! We gonna have a closer look at the AKUBRA project!

15. Thank you for your attention!