Agenda - 18 February 04

1. Agenda - 18 February 04 • Welcome • Round Table - Who? Where? What? • Introduction to FAME • Fame Generic Framework • Overview • Technical components • Round table discussion • Next actions

2. FAME Generic Framework

3. Objectives • To explore and understand the work of FAME pilot streams. • To synthesise views of a deliverable overall generic framework with appropriate (vendor neutral) technical and social/organisational elements. • It is NOT about individual stream level service or software design.

4. Objectives • The generic framework will be the accumulation of ideas and experience from the individual streams together with relevant research input. • It will act as a guide to other LAs in their sourcing and implementation of systems and service development.

5. Headings • High level scoping statement • Legal powers and responsibilities • Governance • Information sharing • Identity management • Infrastructure • Messaging, events and transactions • Sustainability • Federation

6. High level scoping statement • What services are we exploring? • What are the aspirations for outcomes? • How will these outcomes be evaluated? • Takes account of the different requirements of the contexts of: • citizens/communities, • service providers, • service commissioning and • national governance. • Defines the ‘business case’.

7. Legal powers and responsibilities • Defines the multi agency services to be provided (e.g. practice, assessment, care planning and delivery). • Identifies the legislative/guidance framework covering these services. • Identifies the legal powers, statutory duties and responsibilities of the agencies and organisations providing the service.

8. Governance • The organisation of multi agency services and practice. • Information sharing. • The infrastructure- relationships, hard and soft assets. • Procurement and ownership. • Participation of stakeholders in the evaluation of outcomes. • The links to the duties and legal powers available is clearly identified.

9. Information sharing • A multi agency hub facilitates a variety of information sharing modes. • Information sharing may apply in all contexts- amongst citizens, services, commissioning and policy making. • The information sharing protocol will explicitly define the limits information sharing enabled.

10. Identity Management • Identity is more than a personal dataset. • Identity is context dependent and must be defined in terms of relationships. • Statements about identity have a provenance associated with the trustworthiness of their sources. • Extends ideas of identity and consent.

11. Infrastructure • Communication within a multi agency community requires shared resources and capabilities. • The infrastructure must respect appropriate diversity and autonomy as well as commonality and uniformity. • Its use is defined by the user community.

12. Messaging, events, transactions • Process maps, workflows and catalogues may be shared. • The infrastructure will support broadcast, narrowcast publication and may automatically generate: • Notifications • Updates of shared data items, documents and content.

13. Sustainability • A capability for continuous adaptation. • Identifies the scale, scope and context of change. • Links systems and organisational change processes. • Sustains on-going processes for training, review and further development. • Recognises the required skill-sets, project resources, cultural sensitivity and people.

14. Federation • Co-operative working evolves between multi agency communities of service. • Local shared infrastructures can inter-work with other local and national infrastructures. • These processes are facilitated by Internet technologies e.g. portals and hubs/spokes.

15. Headings • High level scoping statement • Legal powers and responsibilities • Governance • Information sharing • Identity management • Infrastructure • Messaging, events and transactions • Sustainability • Federation

16. High level scoping statements High level scoping statements High level scoping statements Governance Governance Legal Powers Legal Powers Infrastructure Infrastructure Information sharing Information sharing Events, Messages & Transactions Information sharing Events, Messages & Transactions Events, Messages & Transactions Governance Identity Identity Identity Legal Powers Sustainability Sustainability Sustainability Federation Federation Federation Project Sponsor Practitioner IT Manager Possible paths through the framework

17. The areas with a strong technical component. Headings • High level scoping statement • Legal powers and responsibilities • Governance • Information sharing • Identity management • Infrastructure • Messaging, events and transactions • Federation • Sustainability

18. Systems and infrastructure An historical perspective

19. Local interaction Local interaction Application layer with local event handling and workflow Application layer Preserves and manages data over space and time Persistent data layer Integrates platforms within an enterprise: our computers and networks become a unified resource Middleware Hardware and Operating System Layer Transaction Management

20. Each of these “integration products” has its own origins in concepts of resource management or process management. Channels Modes and means of access Knowledge Portals Shared Workflow eCommunity Applications are WEB enabled Local interaction Local interaction Application layer with local event handling and workflow Application layer Preserves and manages data over space and time Persistent data layer Integrates platforms within an enterprise: our computers and networks become a unified resource Middleware Hardware and Operating System Layer CRM Transaction Management

21. Channels Modes and means of access Integration layer Resource Integration Portal Identifiers and identities Master Index Shared Workflow and Message Hub Process Integration Application Adapters Local interaction Local interaction Application layer with local event handling and workflow Application layer Preserves and manages data over space and time Persistent data layer Integrates platforms within an enterprise: our computers and networks become a unified resource Middleware Hardware and Operating System Layer Domain of Integration

22. Commodity products and services Support for users to shape and govern their information environment. Local interaction Local interaction The information systems and communications utility. Structure and infrastructure Domain of Integration Channels Integration layer Portal Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

23. Commodity devices and services Integration Engines: CRM, BPR, media/content, Knowledge/document Management Systems Integration and change management. Applications service provision / In-house Local interaction Local interaction Local interaction Local interaction Software development and support Software technology licensing Box shifting Provision value chains Channels Channels Integration layer Integration layer Portal Portal Master Index Master Index Shared Workflow and Message Hub Shared Workflow and Message Hub Application layer Application layer Persistent data layer Persistent data layer Middleware Middleware Hardware and Operating System Layer Hardware and Operating System Layer

24. Commodity devices and services Commodity devices and services Integration Engines: CRM, BPR, media/content, Knowledge/document Management Integration Engines: CRM, BPR, media/content, Knowledge/document Management Systems Integration and change management. Applications service provision / In-house Local interaction Local interaction Local interaction Local interaction Software development and support Software development and support Software technology licensing Software technology licensing Box shifting Box shifting Outsource: we do it all for you… Channels Channels Integration layer Integration layer Portal Portal Master Index Master Index Shared Workflow and Message Hub Shared Workflow and Message Hub Application layer Application layer Persistent data layer Persistent data layer Middleware Middleware Hardware and Operating System Layer Hardware and Operating System Layer

25. Commodity devices and services Integration Engines: CRM, BPR, media/content, Knowledge/document Management Systems Integration and change management. Applications service provision / In-house Local interaction Local interaction Software development and support Software technology licensing Box shifting “Best of breed”: The IT department in control Channels Integration layer Portal Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

26. Government Gateway: Fit a DIS Box and London will do the rest Commodity devices and services Integration Engines: CRM, BPR, media/content, Knowledge/document Management Systems Integration and change management. Applications service provision / In-house Local interaction Local interaction Software development and support Software technology licensing Box shifting Channels Integration layer Portal Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

27. Commodity devices and services Integration Engines: CRM, BPR, media/content, Knowledge/document Management Systems Integration and change management. Applications service provision / In-house Local interaction Local interaction Software development and support Software technology licensing Box shifting Strategic integration: Channels Integration layer Portal Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

28. Other Domains Portal Index Hub Local interaction Local interaction We are not alone: There are other domains around us. Domain of Integration Channels Integration layer Portal Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

29. Other Domains Portal Index Hub Local interaction Local interaction We are not alone: There are other domains around us. Domain of Integration Channels Integration layer Portal Hub to Hub interactions Master Index Shared Workflow and Message Hub Application layer Persistent data layer Middleware Hardware and Operating System Layer

30. Universal point of Access Portal Portal • Is offer X in your catalogue the same as offer Y in mine? • How do we support and nurture brokers and intermediaries? • Sometimes we need to be able to “google” the whole federation… • This universal service enables signaling for an information economy. • Financial cost and value • Social value • Political value

31. Universal point of Publication and Recourse Shared Workflow and Message Hub Hub • The audit trail may lead to a boundary: where do you go then? • Escalation has to stop somewhere. • Can you deliver my scripts and can I deliver yours? • How do I tell the people who need to know? • Individually addressed messages, • Role and workflow based structured messages, • Narrow-cast, • Universal broadcast, • Publication.

32. Master Index X Application xc Application xb Application xd Application xa I have identifier B in domain X Domain id XA and identifier C in domain Y. Domain id XB Domain id XC If application xb needs to talk to application ym about me, then it must do so via a hub to hub message. Domain id XD Master Index Y Application ym Application yk Application yl Application yj This requires that the identity management service, at the federation level, must confirm that XB ≡ YC ≡ “Me”. Domain id YA Domain id YB Domain id YC Domain id YD Identity Management Index Index Who gives the identity management service the right to do this and how?

33. Federal points of access: the catalogue of catalogues Federated Identity Management Services Universal point of publication, recourse and resolution. Local interaction Local interaction Federation Services Other Domains Domain of Integration Channels Integration layer Portal Portal Index Hub to Hub interactions Master Index Shared Workflow and Message Hub Hub Application layer We are not alone: There are other domains around us. Persistent data layer Middleware Hardware and Operating System Layer

34. Accepting networks Identity tokens and keys Local interaction Local interaction Brand Apps Pocketable data Federation Services Other Domains Domain of Integration Channels Federal points of access: the catalogue of catalogues Integration layer Portal Portal Federated Identity Management Services Index Master Index Shared Workflow and Message Hub Hub Universal point of publication, recourse and resolution. Application layer Smart Cards: Integrating the integration technologies Persistent data layer Middleware Hardware and Operating System Layer

35. The areas with a strong technical component. Headings • High level scoping statement • Legal powers and responsibilities • Governance • Information sharing • Identity management • Infrastructure • Messaging, events and transactions • Federation • Sustainability

36. Certification authorities Trust anchors must link root and end entities. A business anchor linking end entities. Hierarchical model

37. Trust anchors must be local. Distributed model Hierarchical model

38. A CA acting as facilitator between CA domains. Bridge model Distributed model Hierarchical model www.projectliberty.org

39. Federation Services Other Domains Domain of Integration Views of federation Channels Federal points of access: Integration layer Portal Portal Federated Identity Services Index Master Index Shared Workflow and Message Hub Hub Universal point of publication. Application layer Persistent data layer Middleware Hardware and Operating System Layer

40. Safe & secure public service infrastructure: • What does Liberty Alliance do? • Best practice PKI to protect the channels and the messages. • Authentication enrolment mechanisms. • A set of mutual and community based trust creation and implementation mechanisms. • Open, progressive and federable approach. But multi-agency public service delivery, particularly the caring services, present more demanding requirements than does commerce.

41. The requirements: • Governance. • who participates in defining the rules and processes? • how is their engagement informed and made effective? • Flexibility. • The process to be supported is the one that reengineers processes and creates new structures. • Trust. • New demarcations between structure and infrastructure. Ideas of identity and of relationship seem to be very significant in addressing these requirements.

42. Events,Messages and Transactions. Some definitions… ….but not just a glossary. We need to be clear about the terms and concepts we use.

43. A state of affairs that could be one way or another. It causes something and so makes a difference. It is communicated, - moving in space and or time. Events→Individuals→Transactions Information • News of a contingency that has significance. • An event: an occasion when information is generated. • Unique birth and death events delimit the existence of an individual, (also known as a principal or a party). • An event becomes a transaction when: • It involves 2 or more individuals and… • Produces intended changes in the distribution of resources and responsibilities among them

44. Transactions→Relationships→Identities • If information from a previous transaction is used, by the same parties, in subsequent ones then this is a relationship. • Multiple encounters • Recognition • Persistence • More and different transactions. • An identity is the information used by parties to recognise each other. • An identifier links an identity to a history. • These definitions lead to two implementation concepts: • A register • Anindex.

45. Register 1 An identity An Individual A local identifier Identity attributes Sets of records of the same individual with different relationships. Profile and history Relationship Rc. Relationship Ra.

46. Domain of Integration Channels An identity A relationship type + A provider identity An Individual Integration layer Portal Rd, Pb Ra, Pb Rg, Pb Rc, Pb Rb, Pb Re, Pb Rf, Pb Associated identifiers An index correlating identifiers Master Index Shared Workflow and Message Hub Local interaction Local interaction Application layer Persistent data layer Middleware Hardware and Operating System Layer Register 1 Sets of records of the same individual with different relationships. Relationship Rc. Relationship Ra.

47. A relationship type + A provider identity Rd, Pb Ra, Pb Rg, Pb Rc, Pb Rb, Pb Re, Pb Rf, Pb Associated identifiers Index based, narrowcast publications: • I, <Na>, having relationship w with individual I know as <Nb>, am willing to enter transactions q, r or s with anyone who has relationships x, y or z with this individual. • With whom can I engage in transaction u, regarding the individual I know as <Nb>? • These may be subject initiated, permissioned, joint or independent of the subject.

48. An identity A relationship type + A provider identity An Individual Associated identifiers Registers which use different attribute sets to indicate identities. Register 1 Rd, Pb Ra, Pb Rg, Pb Rc, Pb Rb, Pb Re, Pb Rf, Pb An index correlating identifiers A domain of integration… …but where is federation? Relationship Rc. Relationship Ra.

49. Register 1 Register 2 Register 3 Identity Management Provider A Identity Management Provider B Rm, Pb IMPb Ra, Pb Rd, Pb Rk, Pb Rc, Pb Rb, Pb IMPa Rl, Pb IMPb Relationship Rb. Relationship Rc. Relationship Rk. Relationship Ra. Registers which use different attribute sets to indicate identities. Rd, Pb Ra, Pb Rg, Pb Rc, Pb Rb, Pb Re, Pb Rf, Pb IMPa Sets of records of the same individual with different relationships in two different domains.

50. IMPb Rc, Pb IMPa Register 1 Register 2 Register 3 • One register • An index of registers and a register of registrars? • One index distributed over the federation. • A universal identity management service. • Multiple registers, indexes and identity management services. Rm, Pb Ra, Pb Rd, Pb Rk, Pb Rb, Pb Rd, Pb Ra, Pb Rg, Pb Rc, Pb Rb, Pb Re, Pb Rl, Pb IMPb Rf, Pb Centralisation policies: