1. Page 1 TSAS: Linda Strick, GMD Fokus strick@fokus.gmd.de Marcel Mampaey, Alcatel marcel.mampaey@alcatel.be TINA Reference Points become an OMG Standard Presentation to the TINA 2000 Conference

2. Page 2 Overview of the presentation and Structure of Submitted Document  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segments (section 6)  Compliance Points (section 8)

3. Page 3 Objectives uThe service requested consists of standardized interfaces and mechanism for n enabling end-users to access and configure a telecommunication service according to their wishes and n to allow value-added service providers to offer their services to End-users. uIt manages contracts for end-users and service providers, n locates matches between user requirements and service providers subscription offers n enables the establishment of mutually anonymous, but authenticated, access between end-user and service provider.

4. Page 4 Submitters  Alcatel  AT&T  Deutsche Telekom AG  GMD Fokus  Hitachi  Lucent Technologies  Nippon Telegraph and Telephone Corporation  Nortel Networks  Siemens AG  British Telecommunications plc.  Cisco Systems  Humboldt University  IBM Telecommunications Industry  KPN Royal Dutch Telecom  Sprint  Sun Microsystems Also supported by:

5. Page 5 TSAS and Parlay  Parlay Group Create an open Application Programming Interface (API) that would enable secure, public access to core capabilities of telecommunication and data networks. Members: AT&T, BT, Cegetel, Cisco, Ericsson, IBM, Lucent, Microsoft, Nortel Networks, Siemens, and Ulticom (formerly DGM&S)  Release 2.1 out now  TSAS: Core part fed into Release 2.0 / 2.1 -> compliant Intend to keep Parlay and TSAS consistent for Service Access and Subscription Provide ‘points of flexibility’ where different approaches are possible - e.g. Authentication

6. Page 6 TSAS and TINA  Most of the specification is based on TINA specs, BUT: The entire specification is re-structured according to the flexible ‘segment’ concept and to OMG guidelines, and modernized according to contributors validation work Core segment is strongly modified and simplified, and aligned with corresponding Parlay 2.1 specs. Service access segments are re-structured and simplified (over- specification suppressed) Subscription segments are re-structured and simplified, information model is updated according to recent evolutions  TSAS specs are fed-back to TINA for endorsement by TINA  Liaison to ITU-T after spec stabilization in OMG for aligning the Q series supplements 27 and 28

7. Page 7  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segments (section 6)  Compliance Points (section 8)

8. Page 8 Response to RFP requirements  Relationship to existing OMG specifications  Mandatory requirements Retailer administration interface requirements Initial access related interface requirements Service access related interface requirements  Optional requirements  Issues to be discussed From the points above: none Security

9. Page 9  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segments (section 6)  Compliance Points (section 8)

10. Page 10 TSAS Architecture Domain Y General principle Provider User Domain X Provider User

11. Page 11 TSAS Architecture Service Provider Domain Retailer Domain Consumer Domain Business Model Subscriber End-User

12. Page 12 Segmentation principles Domain ADomain BDomain C Domainsand interfaces Example of a segment, segments

13. Page 13 Segments Framework  The segment is an optional set of functions  A segment can be activated and de-activated with Framework operations  One segment corresponds to either one set of interface(s) on one domain two such sets of interface(s), each on one of the peer domains  The segments are limited to access functionality, access related functionality (such as invitations), or subscription related functionality

14. Page 14 Segments defined in TSAS  Core segment (mandatory)  Service access segments Invitation segment Context Access Control  Subscription segments Subscriber administration Service provider administration Service Discovery Session Control End-user administration End-user customization

15. Page 15  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segments (section 6)  Compliance Points (section 8)

16. Page 16 TSAS Domains and Roles Service Provider Domain Retailer Domain Consumer Domain Subscriber End-User

17. Page 17 TSAS Domains and Roles User Provider Initial Authentication Access These are symmetrical interfaces

18. Page 18 TSAS Domains and Roles Service Provider Domain Retailer Domain Consumer Domain Subscriber End-User Same interfaces re-used here

19. Page 19 Service Access  Service Access: A consistent approach to allowing users to access telecoms services in a controlled and secure way. Three Phases:  Initial Contact  Authentication  Access

20. Page 20 TSAS phases  Initial Contact - allow both domains to initiate interaction - interface: DfTsas::Initial  Authenticate - allow both domains to authenticate the identity of the other domain - interface: DfTsas::Authenticate - not used if CORBA security is available  Access - allow both domains to access interfaces and services - interface: DfTsas::Access

21. Page 21 TSAS phases: initial contact TSAS ClientDfTsas::Initial Initial Contact TSAS Client gains a reference to DfTsas::Initial of TSAS Provider Authentication initiate_authentication( ) Client initiates Authentication. CORBA Security, TSAS Authentication, or another method may be used request_access( ) Access (start of access phase) Client requests an access interface. TSAS Access interface is returned.

22. Page 22 TSAS ClientDfTsas::Initial DfTsas:: Authentication DfTsas:: Access Initial Contact TSAS Client gains a reference to DfTsas::Initial of TSAS Provider TSAS Client contacts TSAS Provider (application level authentication) initiate_authentication( ) select_auth_method( ) authenticate( ) ( authenticate( ) ) Authentication request_access( ) Access (start of access phase)

23. Page 23 TSAS Client contacts TSAS Provider (CORBA Security used for authentication) request_access( ) CORBA Security is identified as the mechanism used to authenticate domains. DfTsas::Authentication interfaces are not used. TSAS Client DfTsas::Initial DfTsas::Access Initial Contact TSAS Client gains a reference to DfTsas::Initial of TSAS Provider Authentication Access (start of access phase)

24. Page 24 DfTsas::Authentication (on Provider) TSAS ClientDfTsas::Initial DfTsas::Authentication (on client) TSAS Provider initiate_authentication( ) TSAS Client's DfTsas::Authentication reference is passed to TSAS Provider, and its DfTsas::Authentication is returned. TSAS Client contacts TSAS Provider (mutual authentication) select_auth_method( ) authenticate( ) This is an example of a sequence of authenticate operations. Different authentication protocols may have difference requirements on the order of operations. ( authenticate( ) ) request_access( ) If TSAS Client supports DfTsas::Access itfce, its reference is passed to TSAS Provider. TSAS Provider's i_tsasAccess is returned.

25. Page 25 Operations on Access interface  After successful authentication, an access session exists, and the Access interface is available: Interface Access { void select_service ( ) ; void sign_service_agreement ( ) ; void end_session ( ) ; void list_segments ( ) ; void get_segment ( ) ; void release_segments ( ) ; void end_access ( ) ; };

26. Page 26  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segments (section 6)  Compliance Points (section 8)

27. Page 27 Some naming conventions Service Provider Domain Retailer Domain Consumer Domain Ret Cons Ret SP Ret SP Business Model

28. Page 28  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segment (section 6)  Compliance Points (section 8)

29. Page 29 Subscription business model Subscriber Retailer User Signs contract about service usage Uses services Authorize

30. Page 30 Service Provider subscription Service Provider Retailer Sign contract about service retailing Subscription business model con’t Provide service

31. Page 31 Subscription Segments Service Provider Domain Retailer Domain Consumer Domain Subscriber End-User Subscriber/ End-User Admin End-User Customiza tion Service Provider Admin

32. Page 32 Simple Subscription : Subscriber Mgmt :ServiceProfile Mgmt : ServiceTemplate Mgmt : ServiceContract Mgmt : Subscriber : Service Provider 1: deploy_service(in ProviderId, in ServiceTemplate) 2: create_subscriber(in Subscriber) 3: create_service_contract(in SubscriberId, in ServiceContract) assign profile (service or contract) to subscriber 4: assign(in SubscriberId, in SAGId, in ServiceProfileId)

33. Page 33 Subscription with user management 6: create_sag(in SubscriberId, in SAG, in UserIdList) 9: modify_user_service_profile(in SubscriberId, in UserId, in ServiceTemplateId, in PropertyList) : Subscriber : End User : UserDescrip tionMgmt : ServiceProfile Mgmt : SAGMgmt 7: create_service_profile(in SubscriberId, in ServiceProfileId, in ServiceProfile) 8: assign(in SubscriberId, in SAGId, in ServiceProfileId) repeat for each service profile 5: create_user(in SubscriberId, in UserDescription) Repeat for each user

34. Page 34  Objectives of the submission (section 1)  Submitters (section 1)  Response to RFP Requirements (section 2)  Architecture (section 3)  Core Segment (section 4)  Service Access Segments (section 5)  Subscription Segment (section 6)  Compliance Points (section 8)

35. Page 35 Compliance points  Three compliance points defined: Core segment Service access segments Subscription segments

36. Page 36