Proposed KI International Bodies Liaison Relationships and Specifications Roadmap

1. Proposed KI International Bodies Liaison Relationships and Specifications Roadmap Prepared by Abbie Barbir Version: 3.0 Date: April 3rd , 2010

2. Scope of this report Purpose of these report is to help KI determine which International Standardization Bodies it should have relationships Determine the possibility of further standardization of Liberty Specifications in other International Bodies like ITU-T and ISO Immediate technical recommendations for 2010

3. Executive Summary and recommendations for 2010 Establish LS with ITU-T SG 17 ASAP Get A.5 Status (Abbie will start the process) in April 2010 Review KI submission policy to SDO Consider that KI also to own their specifications while submissions to other SDO for further standardization Evaluate working towards making SG 17 to become a Liberty/OpenId adopter and promoter Open discussion about WSF, IAF, IGF in their WG about moving them to international SDOs Evaluate how ISO SC38 will play (still in construction mode) Need to evaluate x.eaa (joint work with ITU-T and ISO and IAF 2.0) and make a decision on how to move forward Need to work closely with US for secure transaction framework in particular Federation technologies and authentication assurance

4. OASIS Experience in ITU-T OASIS first attempt in 2004 to standardize SAML and XACML in the ITU-T failed badly. Reason, they were perceived as outsiders trying to dictate their way on the ITU-T. Situation was corrected when OASIS started dealing with an ITU-T insider that followed the ITU-T process in Recommendation development. In 2005, OASIS had a great success in working with the ITU-T in particular SG 17 (see ITU-T background slides) At this time OASIS SAML, XACML and CAP 1.1 are also ITU-T Recommendations OASIS Plans additional submissions to the ITU-T SG 17 of many of the Identity related specifications

5. OASIS Experience in ITU-T • OASIS worked agreements with the ITU-T that help ensures that the OASIS specifications are aligned with OASIS. Agreements include the following • OASIS is the owner of the specification • OASIS has the first and final say in determining how the specification evolve. ITU-T can submit requests for improvement for OASIS for review • OASIS passes the requests to the proper TC • This mandate required that the TC can stay in maintenance mode • OASIS will deal with the situation when the TC is closed • OASIS IPR polices are carried and adopted as part of the ITU-T adoption step of the specification • OASIS will ensure that the OASIS and ITU-T versions are aligned. This is done through updated submissions from OASIS to the ITU-T

6. OASIS Experience in ITU-T OASIS and ITU-T also agreed on promoting the adopted specifications. Many joined workshops on CAP 1.1 ITU-T promoted SAML and XCAML as part of their report on Cybersecurity to the United Nations and security workshops. OASIS had one and only one point of contact between them and the ITU-T (I am the contact)

7. Criteria for Submitting a Specification to the ITU-T/ISO for Further Standardization • What does further standardization mean? • Obtaining an international status from the ITU-T as Recommendation xxx… • ITU-T can suggest improvements, but these improvements will have to be agreed upon and done at KI.

8. Criteria for Submitting a Specification to the ITU-T/ISO for Further Standardization Specification has to be mature and stable Specification should be well adopted or at least has the potential to be well adopted at a later stage Specification has a clear roadmap of evolution and a clear mandate from the submitter organization to progress and maintain it (at least..) It is preferable that the submitted specification Not to compete with another internally developed specification or a specification that is under development. In the later case merging the two specifications is a possible outcome. ISO is more strict on competing specification. ITU-T is more relaxed.

9. What Does Submitting a KI Specification to ITU-T Means? • If agreements are based on OASIS style, then • KI is still the owner (can give that up if it wishes or work a sharing agreement if it wishes..) • KI maintain the specification (can give that up or work a sharing agreement if it wishes..) • There is a way to submit a specification to the ITU and make it also an ISO specification ( get 2 birds in one shot, slower but possible..). The joint text between ITU-T and ISO can also be stopped at any time (basically revert to ITU-T only submission)

10. What is ITU-T A.5 Qualification In the ITU-T Recommendations, a reference to an external work is strictly controlled. Recommendations need to explain why the are referencing external work and need a justification for it. This step is needed to ensure the excellent quality of ITU-T work where references are guaranteed to be available for a long time. ITU-T assess external organizations and determines if they do qualify to be quoted in ITU-T Recommendations. This step is called obtaining A.5 qualifications. Examples of Organizations Qualified for Including References inITU-T Recommendations under Rec. A.5 Procedures are given in http://www.itu.int/ITU-T/lists/qualified.aspx#organizations Liberty Alliance was A.5 qualified. KI needs to do the same. This can be done by sending an LS to Mr. Georges Sebek at the ITU-T SG 17.

11. What Liberty Specification to Send to the ITU-T for Further Standardization • Liberty ID-WSF 2.0 as a whole package. • Submit the whole sets of document as s one recommendation • Liberty SIS Specifications • Each specification can be submitted as a separate Recommendation. • Submit individual specifications when WSF 2.0 is approved (basically about six months from WSF 2.0 submission) • IGF V1.0 • This framework can be submitted provided that it meets the maturity and adoption criteria. It is not clear to me at this stage that the framework policy and language components are final and concrete • Submission can include a road map for more specification maturity. • IAF is already in ITU-T and ISO and is good as is • What to do with IAF 2.0

12. KI and ITU-T Liaison and Specification Roadmap What does KI need to do now Possibly Inform ITU-T about the interest in A.5 qualification. On the other hand I can initiate the process from the ITU-T end in April Inform the ITU-T about the intention of using the ITU-T for further standardization of the WSF 2.0 framework ( aka OASIS like agreement) Indicate that the December SG 17 meeting is the intended date for further collaboration

13. KI and ISO ISO has started SC 38 a new sub committee with focus on web services, security and cloud computing (cloud is only a study group with no standardization mandate) ISO SC38 can be a place for standardizing some of KI work in particular WSF 2.o and the ID- SIS KI may need to apply and qualify for a fast track qualified organization in order to standardize the work (ie rubber stamp it) On the other hand the work can be submitted to SC38 for further standardization (may be accepted as is ( ( there is also risk of having it modified and/or refused )) KI will need to establish an LS relationship with SC 38

14. ITU-T Recommendation Time Line In order to shorten the length of time of having a recommendation from KI adopted in the ITU-T, it is advised that to indicate your intentions as early as possible in the game. As such, KI should inform the ITU-T through and Liaison statement its intentions with respect to WSF and SIS individual specifications. Provided that KI is A.5 qualified then in general, the steps and time include the following: Convert the KI specification into an ITU-T Recommendation format Send an LS statement and the recommendation to Q10/17 asking for adoption by the ITU-T in a fashion that is similar to SAML using the fast approval process (AAP). This should be done 4-6 weeks before a regular ITU-T SG 17 meeting. SG 17 meets twice a year. Next two meetings are in April and December of 2010

15. ITU-T Recommendation Time Line It is still possible to send an LS to SG 17 (need to be send by April 2nd ) to indicate KI intentions regarding WSF 2.0 What happens then at the ITU-T is the following: The LS is discussed in Q10/17 and is put on the Agenda by the Rapporteur (currently I am the Rapporteur). Based on the members consensus an draft recommendation is established for the submitted specification. The Rapporteur can indicate that the draft recommendation is due for determination in the next meeting of the SG 17 (December 2010, if we miss this time line, then we can submit in December 2010 and ask for determination in the April 2011 meeting)

16. ITU-T Recommendation Time Line After determination, the recommendation is adopted and is given an official number. Then the TSB (i.e. publication department) will follow the ITU rules in ensuring that the text meets all the ITU standards. Final publication is done with 3-5 months depending on how busy the TSB is. Please note that as opposed to ISO, ITU-T recommendations are available free of charge to the general public.

17. ITU-T Vs ISO ISO and ITU-T provide internationalization recognition to KI standards ITU-T provides a better place for KI at the initial stage since KI can have better control on the process (aka OASIS experience) ISO SC 38 has not started yet and the politics in it are not known yet ITU-T recommendations are available free of charge, while ISO recommendations are not ITU-T recommendations can also be cross listed with ISO (Slower but definitely feasible)

18. ITU-T Background

19. ITU-T Overview Review ITU-T Study Groups (SG) main organs Provide Overview of SG Structure, organization, focus and role

21. ITU Structure Plenipotentiary Conference ITU Council ITU-T World Telecommunication Standardization Assembly ITU-R World Radiocommunication Conference Radiocommunication Assembly ITU-D World Telecommunication Development Conference General Secretariat

22. WP WP WP WP ITU-T Structure WTSA World telecommunication standardization assembly WTSA World Telecommunication Standardization Assembly Workshops, seminars, symposiums, … TSAG JCA IPR Promo. SG … SG GSI FG Flagship group Q Q Q Q Question: Develop Recommendations Regional group Q Q

23. ITU-T Objectives • Develop and publish standards for global ICT interoperability • Identify areas for future standardization • Provide an attractive and effective forum for the development of international standards • Promote the value of ITU standards • Disseminate information and know-how • Cooperate and collaborate • Provide support and assistance

24. ITU-T Key Features • Truly global public/private partnership • 95% of work is done by private sector • Continuously adapting to market needs • Pre-eminent global ICT standards body

25. Study groups (2009-2012)

26. Cybersecurity • ITU-T X.1205, Overview of cybersecurity • Cybersecurity is the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance and technologies that can be used to protect the cyber environment and organization and user’s assets. Organization and user’s assets include connected computing devices, personnel, infrastructure, applications, services, telecommunications systems, and the totality of transmitted and/or stored information in the cyber environment. Cybersecurity strives to ensure the attainment and maintenance of the security properties of the organization and user’s assets against relevant security risks in the cyber environment. The general security objectives comprise the following: • Availability • Integrity, which may include authenticity and non-repudiation • Confidentiality

27. Strategic context • WSIS Action Line C5, Building confidence and security in use of ICTs • PP-06 Resolution 130, Strengthening the role of ITU in building confidence and security in the use of information and communication technologies • Director of TSB to develop projects for enhancing cooperation on cybersecurity and combating spam responding to the needs of developing countries • PP-06 Resolution 149, Study of definitions and terminology relating to building confidence and security in the use of information and communication technologies • To establish a WG of the Council to study terminology re. building confidence and security in use of ICTs • WTSA-08 Resolutions 2, 50, 52, 58, 76 • Mandate for ITU-T SG 17, cybersecurity, countering and combatting spam, encourage the creation of national CIRTs, particularly for developing countries, studies relating toconformance and interoperability testing, assistance to developing countries, and a future possible ITU Mark programme

28. ITU-T SG 17 role and mandate • Responsible for studies relating to security including cybersecurity, countering spam and identity management. Also responsible for the application of open system communications including directory [X.509] and object identifiers, and for technical languages, the method for their usage and other issues related to the software aspects of telecommunication systems. • Lead study group on telecommunication security, identity management (IdM) and languages and description techniques

29. SG 17 structure Identity management and languages Network and information security Q10IdM Securityproject Q1 Application security Ubiquitousservices Q6 Q11Directory Q2Architecture Q7 Applications Q12ASN.1, OID Q3ISM Q13Languages Q8SOA Q4Cybersecurity Q14Testing Q9Telebiometrics Counteringspam Q5 Q15OSI WP 1 WP 2 WP 3 Res.50 Res.52 Res.58 Res.76

30. Selected Example of ITU-T SG 17 security projects and initiatives

31. ITU-T security project Q.1/17 • Security Coordination • Coordinate within SG 17, with ITU-T SGs, with ITU-D and externally • Keep others informed - TSAG, IGF, ISO/IEC/ITU-T SAG-S… • Participate in workshops/seminars and to GSC • Maintain reference information on LSG security webpage • Security Compendium • Regularly update the catalogue of approved security-related Recommendations and security definitions extracted from those approved Recommendations • ICT Security Standards Roadmap • Keep updated the searchable database of approved ICT security standards from ITU-T and others (e.g., ISO/IEC, IETF, ETSI, IEEE, ATIS) • ITU-T Security Manual (4th edition completed 4Q/2009) • Business use of telecommunication/ICT security standards (new initiative)

32. Cybersecurity information exchange CYBEX (1) Q.4/17 • A global initiative to • identify a set of platform specifications for the trusted exchange of information among responsible parties worldwide essential for cybersecurity for • Infrastructure protection • Incident analysis and response • Law enforcement and judicial forensics • Enhance the availability, interoperability, and usefulness of these platforms • Extensible use of best-of-breed open cybersecurity information exchange platforms • Facilitated by the work of ITU-T Q.4/17 • Recommendations planned during 2010-2011, with continuing evolution to current user community versions and needs

33. Cybersecurity information exchange CYBEX (2) Contractual service agreements and federations Intergovernmental agreements and cooperation Encryption/ VPNs esp. for signalling Legal remedies may also institute protective measures 1. Measures for protection Tort & indemnification 4. Legal Remedies Resilient infrastructure Real-time data availability Regulatory/ administrative law 2. Measures for threat detection Criminal law Data retention and auditing Forensics & heuristics analysis Provide data for analysis Identity Management Routing & resource constraints Provide basis for actions Blacklists & whitelists Deny resources Investigation & measure initiation Reputation sanctions Vulnerability notices Patch development Network/ application state & integrity Provide awareness of vulnerabilities and remedies 3. Measures for thwarting and other remedies = information exchange for analysis = information exchange for actions

34. Cybersecurity information exchange CYBEX (3) Cybersecurity Organizations Cybersecurity Organizations • Structure information • Identify & discover cybersecurity information and organizations • Trusted exchange of cybersecurity information CybersecurityInformationuse(out of scope) CybersecurityInformationacquisition(out of scope) For each area: Identify existing standards and bring some of them into ITU-T as X-series Recommendations and supplement as needed for global interoperability

35. A global cybersecurity namespaceX.cybex.1 Joint ITU-T & ISO/IEC responsibility [jointly allocated by ITU-T SG 17 and ISO/IEC JTC 1/SC 6] Joint ITU-T & ISO 0 1 2 [jointly allocated by ITU-T SG 17 and ISO/IEC JTC 1/SC 6] Non-country organizations can also be allocated numeric identifiers above 1000 ITU-T|ITU-R ISO [Allocated by ITU-T SG 17] [Allocated by ISO/IEC JTC 1/ SC 6] 3 1 48 = cybersecurity . . . 4 0 2 48 FIRST Every country has a numeric identifier automatically reserved in the OID 2.48 cyber security namespace France Suisse . . . . . . . . . 1001 . . . 4 250 756 840 USA Afghanistan 1 [each country , organization, subdivision allocates namespaces and levels as desired]

36. Identity management (IdM) Q.10/17 • Chair Abbie Barbir • IdM is a security enabler by providing trust in the identity of both parties to an e-transaction • IdM also provides network operators an opportunity to increase revenues by offering advanced identity-based services • The focus of ITU-T’s IdM work is on global trust and interoperability of diverse IdM capabilities in telecommunication. It is not in the development of standards for new IdM solutions. Rather it is focused on leveraging and bridging existing solutions

37. ITU-T SG 17 Question 10/17 • Identity management architecture & mechanisms Motivation • This Question is dedicated to the vision setting and the coordination and organization of the entire range of IdM activities within ITU-T • Recommendations: X- and Y-series • Questions: ITU-T Qs 1, 4, 8/17 and 16/13 • Study groups: ITU-T SGs 2, 11, 13 and 16; ITU-D SG 1 • Standardization bodies: ISO/IEC JTC 1 SCs 6, 27 and 37; IETF; ATIS; ETSI/TISPAN; OASIS; Kantara Initiative; OMA; NIST; 3GPP; 3GPP2 • Other bodies: Eclipse; OpenID Foundation; etc.

38. Recommendation Road Map

39. Recommendation Summaries • X.1250 Capabilities for enhanced global identity management trust and interoperability • X.1251 A framework for user control of digital identity • Defines a framework to enhance user control and exchange of their digital identity related information • X.1252, Baseline identity management terms and definitions • Provides a collection of terms and definitions used in identity management (IdM). • X.1275, Guidelines on protection of personally identifiable information in the application of RFID technology • Provides guidelines regarding the RFID procedures to protect personally identifiable information • X.authi, Authentication integration in identity management • Provides a guideline for the telecom operators to implement the authentication integration of the network layer and the service layer • X.eaa, Information technology – Security techniques – Entity authentication assurance • This Recommendation | International Standard concerns entity authentication assurance. It provides a life cycle framework for the assurance of an entity’s identities in given contexts

40. Recommendation Summaries • X.EVcert, Extended validation certificate framework • Adopts the CA Browser Forum specification to support very high assurance trust and security mechanisms for transactions between end users and organizations that provide high value or critical services or code • X.giim, Generic identity management interoperability mechanisms • Defines mechanisms to support interoperability across different identity management (IdM) services • X.idm-dm, Common identity data model • Develops a common data model for identity data that can be used to express identity related information among identity management (IdM) systems. • X.idm-ifa, Framework architecture for interoperable identity management systems • Proposes a blueprint for a modular framework architecture for identity management systems. The architecture is expected to serve as a reference while discussing, designing and developing future interoperable identity management (IdM) systems. The architecture is intended to be generic in order to satisfy versatile requirements of user-centric, network-centric and service-centric IdM systems. • X.idmgen, Generic identity management framework • Generic framework for identity management (IdM) that is independent of network types, technology or vendor specific products used to provide solutions, and operating environment

41. Recommendation Summaries • X.idmsg, Security guidelines for identity management systems • Proposes security guidelines on how an IdM system should be deployed and operated for secure identity services in NGN (next generation network) or cyberspace environment. • X.priva, Criteria for assessing the level of protection for personally identifiable information in identity management • Defines criteria for assessing the level of protection for personally identifiable information (PII) of the identity provider and the relying party concerned in identity echo system

42. Q10/17 Coordination and collaboration on identity management Windows CardSpace ITU-T Joint coordination activity in IdM JCA-IdM