IDEF Work Group Charter

1. WG NAME (and any acronym or abbreviation of the name):

Identity Ecosystem Framework (IDEF) Work Group

2. PURPOSE: Please provide a clear statement of purpose and justification why the WG is necessary.

The purpose of the Work Group is to maintain, enhance and promote adoption of the IDEF framework--including a high-level systems architecture and a conformance-assessment scheme--for a secure, resilient, scalable, inter-operable, practical, cost-effective and privacy-preserving identity infrastructure for conducting transactions on the Internet.

The framework will incorporate or map to established standards, schemes and recommendations that address some of these performance goals, such as the Kantara 800-63-3 identity-assurance scheme.

By identifying gaps, inconsistencies and commonalities among the variety of incomplete or inconsistent mandates, standards, schemes and recommendations in this space it will reduce confusion and risk for both vendors and implementers of identity and access-management (IAM) solutions. Defining the framework will also identify those areas where additional technology or standards work is needed to achieve the defined performance goals, such as for supporting cross-federation transactions, allocation of liability, and federating authorization attributes.

3. SCOPE: Explain the scope and definition of the planned work.

This Work Group will maintain, enhance and promote the use of the IDEF framework initially developed by the Identity Ecosystem Steering Group, Inc. 

The WG's primary focus is to maintain and evolve the IDEF framework, including: the architecture (as currently represented in the IDEFv1 Functional Model artifact); Requirements (with related guidance material) service providers must meet to implement IDEF-compliant services; and a conformance and assessment scheme, in anticipation that these will be implemented via the KI Assurance Review Board.The WG proposes to manage the evolution of the IDEF generally following the model of Kantara's existing Identity Assurance Frameworks.

The scope of the IDEF architecture extends beyond a set of requirements for secure transactions. It includes, for example, a description of mechanisms for overall coordination of the Identity Ecosystem. The scope of the IDEF includes privacy as well as security; it also includes authorization in addition to authentication. Given a core objective of scalability, the Framework's scope also includes cross-federation inter-operability and the derived requirements like semantic inter-operability via mapping or standardization.

The IDEF WG will establish sub-working-groups as required, defined around activities ancillary to maintenance of the Framework itself. Initially these include:

1. Service Assessment Scheme & Mappings (SASM) sub-WG: develop and maintain the criteria for conformance with IDEF Requirements for self- and third-party assessors; coordinate with ARB and IAWG; map IDEF Requirements and assessment criteria to other frameworks to facilitate reciprocal acceptance of conformity assessments. 
2. IDEF Profiles sub-WG: apply the Framework to specific sectors like Healthcare to develop use-case or sector specific solution architectures.  
3. IDEF Registry sub-WG: in coordination with the Trust Framework Operations Program, develop requirements, a development road-map and funding strategy for sustaining and enhancing the KIEF IDEF Registry; in coordination with the ARB and IAWG, develop a strategy for implementing 3rd-party IDEF conformance assessment (as appropriate) and for supporting other Kantara frameworks within the Registry. 

In addition to serving as WG lead in the areas indicated, these sub-WGs will contribute to the principal WG deliverables—the Framework artifacts.

The WG will submit comments as appropriate on drafts of IAM-related standards, programs or mandates developed by other organizations.

The WG will develop reports for consideration by the LC as Kantara Reports on IAM topics related to the development of the Framework.   

Out of scope: the WG does not anticipate developing reference implementations of IDEF-conformant identity services, or commercial software products. The WG does not anticipate providing any IDEF services itself though there is some possibility of a requirement for some inter-federation coordination facility which may be appropriate for KI to provide in an operational role. 

4. DRAFT TECHNICAL SPECIFICATIONS:List Working Titles of draft Technical Specifications to be produced(if any), projected completion dates, and the Standards Setting Organization(s) to which they will be submitted upon approval by the Membership.

1. IDEF v.1.1 Requirements and Supplemental Guidance. This will be a minor update to the existing IDESG IDEF v1, incorporating work-in-progress modifications in response to self-certification experience of initial IDEF Registry registrants, plus other revisions proposed by IDESG Committees but not advanced through the IDESG approval process. The target date for WG approval of IDEF v1.1. is December 1, 2018.
   
   
2. IDEF v.2 Including Requirements and Supplemental Guidance, but also revision of the IDEF v.1 Functional Model (the IDEF architecture document) and Glossary. It is expected that IDEF v.2 will include new or substantively revised Requirements requiring recertification of registrants (self-, 3^rd-party or combination.) The target for WG approval of IDEF v.2 is December 2019.

5. OTHER DRAFT RECOMMENDATIONS: Other Draft Recommendations and projected completion dates for submission for All Member Ballot.
Deliverables below augment earlier versions of the IDEF already located in the Kantara Initiative Educational Foundation Inc. 

1. IDEF v.2 Service Assessment Scheme. Lead: SASM sub-WG. This will define specific tests, compliance certifications, etc. for assessing a service provider's offering against the IDEF v.2 Requirements. These will be suitable for use by a 3rd party assessor where that is appropriate or required for the level of certification applied for.  Target: December, 2019.
   
   
2. IDEF v.2 Mappings. Lead: SASM sub-WG. These will include at least an updated mapping between Requirements of IDEF v.2 and the current KI IAWG framework. Target date December 2019. Other mappings.e.g., to GDPR, may be undertaken, depending on sponsorship and SME resources available.
   
   
3. Healthcare Identity Assurance Profile of IDEF. Lead: IDEF Profiles sub-WG. Subject to identification of sponsorship, an IDEF-based sector-specific architecture will be developed in conjunction with the Health Identity Assurance WG. Target date and scope will depend on availability of sponsor support.
   
   
4. IDEF Registry Phase 2 enhancement. Lead IDEF Registry sub-WG. The sub-WG will respond with appropriate activity resulting from the KIEF's success in obtaining funding to add IAM capability and support for IDEFv2 to the Registry service; the sub-WG will lead on behalf of the IDEF WG's role as IDEF Registry steward to implement enhancements in coordination with related KI groups and programs. Target date: identification of funding sponsorship: December 2018; IDEF Registry enhancement operational December 2019.  

6. LEADERSHIP: 

The Chair of the IDESG TFTM Committee shall serve as interim WG Chair, pending election of permanent leadership by vote of WG Participants at the initial WG meeting. 

WG elected leadership roles will be a Chair and Vice-Chairs who will also serve as team leads for the WG's sub-work groups.

A qualified Editor and a Secretary will be appointed by the WG Chair with the advice of WG voting Participants.

Duties of the persons occupying the above roles are as defined here.

7. AUDIENCE: Anticipated audience or users of the work.

The anticipated audiences for the Identity Ecosystem Framework (IDEF) and related work of the IDEF WG include: 

1. Providers of identity-related services on the Internet.–IDPs, providers of authoritative authentication or authorization attributes, primary or second-factor authentication service providers, etc. may wish to display an IDEF trust-mark to show they offer services that are both secure and privacy-preserving. They may also be interested in participating in the development of IDEF Requirements and guidance documents to gain early visibility into possible changes of requirements or assessment criteria, and to participate in developing the changes.  
2. Providers of Internet information services that use identity services to control access to their resources ("relying parties.")–RPs selecting products or services to implement their own IAM infrastructures, or assessing potential outsourced IAM services, or IDPs from which they will accept federated identities may use the IDEF trust-mark as a requirement. RPs may also be interested in participating in extending the IDEF Framework to better serve their IAM business needs, e.g., by providing guidance for IDEF compliant consumer IAM or IoT use-cases.   
3. Software and hardware developers and vendors whose customers are identity-service providers or relying parties.–Vendors selling products to identity-services providers may wish to show that their products can be used in an IDEF-compliant configuration of an IDP, RP or other service.
4. End-users.–Both individual end-users and companies doing business on the Internet must assess whether the services they use provide security and privacy protections sufficient for their Internet transactions. The IAM infrastructure supporting these transactions is perhaps the most important layer of protection. The risks for businesses are not only the potential compromise of sensitive information, cyber-theft or fraud, or business continuity, but also fines or legal liability if they are determined not to have taken reasonable steps to protect information. Relying on trust-marked products and services can be evidence of diligence on the part of a business that is a data owner or custodian.
5. Public policy authorities and advocates.–Those responsible for making–or advocating for–laws and regulations have an interest in knowing that compliance with mandates for privacy and security of digital information will not be infeasible or impractical. Definition of an identity ecosystem framework that is based on available (or soon-to-be-available) commercial products can provide an existence proof of the practicality of the assurances provided by the framework.             

8. DURATION: Objective criteria for determining when the work of the WG has been completed (or a statement that the WG is intended to be a standing WG to address work that is expected to be ongoing).

The IDEF WG's program of evolving and promoting the IDEF is anticipated to be on-going. Releases of the Framework specifications and collateral artifacts will have defined scopes and target completion dates. 

This Charter will be reviewed and the proposed revised version submitted to the Leadership Council by December 15, 2019, or earlier if changed circumstances so warrant. 

9. IPR POLICY:  The Organization approved Intellectual Property Rights Policy under which the WG will operate.

The Work Group will operate under the Kantara default Non-Assertion Covenant IPR policy. 

10. RELATED WORK AND LIAISONS:  Related work being done in other WGs or other organizations and any proposed liaison with those other WGs or organizations.

Closely related work includes KI IAWG frameworks and assessment criteria; also related will be the Health Identity Assurance WG program. The IDEF WG also expects to leverage the extensive privacy-related work completed and on-going within Kantara, e.g., in User-Managed Access and Consent Receipts, as well as the work of the Federation Interoperability WG. 

Beyond the obvious linkage to the Kantara Initiative Educational Foundation Inc as the repository of the source documents of this work, Liaison relationships will be established as needed to other KI groups and should include IAWG, HIAWG, the Assurance Review Board, the Trust Framework Operations Program, and Kantara Europe.

The IDEF WG will maintain a liaison relationship with the European Association for E-identity and Security (EEMA) as a WG-level relationship within Kantara's existing organizational-level relationship with EEMA established in 2016. 

In coordination with the Health Identity Assurance WG, the IDEF WG will explore the potential for formal or informal liaison relationships with the Healthcare Information and Management Systems Society (HIMSS) and with the CARIN Alliance.

11. CONTRIBUTIONS (optional): A list of contributions that the proposers anticipate will be made to the WG.

The WG will be directed to the source IDEF framework artifacts in the Kantara Initiative Educational Foundation, Inc. (KIEF) —Functional Model, Requirements and Supplemental Guidance, and Glossary—plus IDEF-KI Mapping and all IDESG Committees' work-in-progress.

12. PROPOSERS: Names, email addresses, and any constituent affiliations of at least the minimum set of proposers required to support forming the WG. At least 3 proposers must be listed. At least 2 of the proposers must be Kantara Initiative Members - {_}{+}https://kantarainitiative.org/members/+_

Martin Smith    –     martin.smith@acm.org   – Individual member
Ben Wilson      –     ben.wilson@digicert.com  –  DigiCert, Inc.