Proposed charter - Agile meeting version

Owned by Armin Kathrein
Jul 24, 2019
5 min read

wwwwwProposed Charter:  Created by Tom Jones, Edited by members listed at bottom; last modified at Agile meeting on 2018-06-26


(1) WG NAME:
Federated Identity Resilient Ecosystem (FIRE) Work Group


(2) PURPOSE:
For identity ecosystems, where there is not a single national electronic ID, it is important that a wide variety of identifiers be acceptable at a wide variety of relying parties. Such a system must work reliably with federations of all sorts, both highly structured and (DIDs).
The purpose of this Work Group is to enhance platform adoption by:

  • Making it easy for users and relying parties to conduct business in a secure and private manner during their engagement. (peace of mind)
  • Giving the Relying Party an environment where they can securely authenticate users while respecting their privacy.
  • Building on prior NSTIC efforts to create the requirements for any digital entity to establish connections with the appropriate level of assurance among all participates that rely on the identifiers, attributes, behaviors and implications of users to enable data interchanges. The ecosystem needs to be resilient in establishing connections as rules and regulations inevitably change over time.
  • Specifically the requirements for these four categories of digital entity will be addressed:
    • User Agents for both mobile and desktop use
    • Identity Providers
    • Relying Parties
    • Trust Service Providers and others providing a wide variety of services.
  • Developing domain-specific profiles to enhance and expand the scope of Kantara certification profiles, including, for example, the following:
    • Privacy
    • Usability
    • Healthcare
    • Financial services
  • Establish the criteria for entities to assure that they are a part of, and compliant with, the profile for their federation. This may include the way that entities' identities are clearly established and attested with each other and with the users.

Baseline requirements.

  • This will include a full list of the individual requirements to be assessed.
  • Self-assessment may be enabled for limited-assurance components.

To create: Creating a web-accessible listing of any compliant entities showing their compliance with all aspects of the requirements as they are established.

To promote: Promoting FIRE adoption -

  • Documents that can be read by someone with a basic education
  • For example, by offering support for profiling and extension creation and creating educational materials.

To promote: Promoting interoperability of independent implementations of FIRE.

(3) SCOPE: Explain the scope and definition of the planned work.
Deliverables must meet the following core design principles:
 Resilient: will function to acceptable levels as regulations, user needs and technologies evolve.
 Simple: Simple to understand, implement in an inter-operable fashion, and deploy on an Internet-wide scale
 Interoperable: Solutions can be developed rapidly using contributed open source examples
 Usable: ease of end-user experience must be demonstrated and verifiable for an identified set of use cases or personas as selected and documented by the work group.


They must also meet the following functional requirements:
Privacy: Protect the privacy of all individuals whether real-world or pseudonymous by protecting the personal information of the user and collecting and sharing as little information as required by the needs of the services requested by the user,
 Security: Protect access to user private data as well as to web site resources.
 ID-agnostic: Agnostic as to the identifier systems used in an individual's various services on the web, in order to allow for deployment on the web as it evolves.
 Authentication: Enable the full extent of assurance as to the identifiers and attributes shared by the user as technologies evolve,
 Modular: (e.g., incorporating other existing specifications by reference where appropriate, and breaking down this Work Group's draft specifications into multiple pieces where reuse by different communities is likely)
Support the notion of a distinct online service for managing data-sharing and service- and device-access relationships between an individual and other parties that request such access,
 Allow a person (real-world or pseudonym) to stipulate the terms and conditions under which they share information with digital entities, including complete termination of the relationship to the full extent permitted by relevant legislation,
Allow a person to query the current information held and change the stipulations under which the service shares their data, including the ability to propagate any changes to existing third party sharing agreements and data collections.
 Allow requesting services to interact directly with responding services in a fashion guided by policy while an individual is offline, while still giving users notification only when action by the user is required.
 Solutions that enable mobile apps to fully participate in this compliant identity ecosystem.

(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.

The following technical specifications may be developed in 2018:

  • Full query at any time by any internet- connected device of the results of any assessment of digital entities incorporating the IDEF registry.
  • Details requirements documentsSuggestions for additional service assessment criteria to enable third party auditors of participants in the ecosystem who assert compliance with the IDEF Baseline Requirements.
  • Respond to input on existing IDEF Baseline Requirements (for example clarifications or updates.)


(5) OTHER DRAFT RECOMMENDATIONS: 

Other Draft Recommendations and projected completion dates for submission for All Member Ballot.

The following reports are anticipated to be developed as time and resources permit.

  • Business value propositions for the use by Relying Parties.
  • User agent assured security requirements.
  • Profiles for use of the recommendations by specific vertical industries or applications.


(6) LEADERSHIP: Proposed WG Chair and Editor(s) subject to confirmation by a vote of the WG  Participants.
At the time of this charter, following are the members of the leadership team:

  • Chair:
  • Vice-chair:
  • Secretary:
  • User Experience and Research Editor:
  • Document Editor:


(7) AUDIENCE: Anticipated audience or users of the work.
Two distinct documents with distinct audiences.

  • The anticipated audience for the primary documents produced by this Work Group includes developers, deployers, and designers of digital services, including IoT device ecosystems that act on behalf of natural and legal persons, including legal representatives of organizations operating such services.
  • Auditors and other assessors for the documents that specifies the requirements as individual line items.


(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).

This is intended to be a standing Work Group to address work that is expected to be ongoing.


(9) IPR POLICY: The Organization approved Intellectual Property Rights Policy under which the WG will
operate.
Kantara IPR Policy - Option Patent and Copyright Reciprocal Royalty Free (need correct link)


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.
This Work Group has a number of dependencies on, and shared goals with, the output of other efforts both inside Kantara and other industry work groups. The Kantara groups and external efforts with which this Work Group intends to liaise informally include (but are not limited to):

NIST identity group
Kantara Consent and Information Sharing and Management Work Groups
OpenID Foundation work groups
Open Identity Exchange
IETF OAuth Working Group

(11) CONTRIBUTIONS: A list of contributions that the proposers anticipate will be made to the WG.
IDEF baseline requirements and supplemental guidance.


(12) PROPOSERS: Names, email addresses, and any constituent affiliations of at least the minimum set of proposers required to support forming the WG.


The original proposers of the Work Group were:
Jim Kragh

Former user (Deleted)

Jeff Brennan
Ben Wilson
Tom Jones