Claims Agent Charter

Version 1.4

Status

 * 10-Jan-2011: v1.4: craigwi: incorporated feedback from conference call
 * 09-Jan-2011: v1.3: craigwi: incorporate feedback from early reviewers
 * 07-Jan-2011: v1.2: craigwi: added initial scenarios; reworked language around components .vs. active client; other clarifications.
 * 04-Jan-2011: v1.1: ptrevithick: renamed from Claims Broker to Claims Agent
 * 30-Dec-2010: v1.0: ptrevithick: charter circulated for discussion period within Stewards Council

Name
Claims Agent Working Group

Purpose
The purpose of this working group is to (i) create a forum for the development of standards-based, interoperable, verified claims agent implementations (which would include both open source and commercial components), to (ii) initially focus on specific scenarios that the community and customers work together to implement and deploy end-to-end and (iii) provide funding and other incentives for the development of open source components. A verified claims agent is a set of software components that allows the user to utilize claim-sets from different sources at relying parties (RPs) of their choosing, under their control, using technology that helps to protect their privacy and helps to ensure the security of the system end to end. Verified claims come from sources that do the verification and digitally sign the claims-sets; the agent itself does not do the verification and do not resign the claims or sets. The agent has the following characteristics:
 * MUST be able to be used with an unmodified browser (includes all types of desktop and mobile devices; support for specific platforms and browsers TBD); this capability would be supported by a “cloud hosted” agent and would support many, but not all of the possible privacy and security features.
 * MUST be possible to configure the system to prevent claims providers from being able to trivially track the use of a claims-set. MUST also be possible to configure the system to prevent trivial correlation of claims-sets delivered to different recipients. Both of these capabilities can be achieved by so-called minimal disclosure technologies based on zero knowledge cryptographic techniques or equivalent techniques.
 * MUST provide mechanisms to mitigate be possible to prevent the theft or lending of claims sets; e.g., claims sets could be cryptographically bound to a device such as a TPM chip, smart card, or phone.
 * MAY include components downloaded to the user’s desktop or mobile device (e.g., a browser extension) to provide additional privacy and security features; e.g., used to invoke the agent service while reducing the phishing attack surface; store information local to the device; prevent the agent service from observing the flow of claims from provider to RP.
 * Components downloaded to the user’s desktop or mobile device MAY also enhance the user experience, but MUST remain aligned and conceptually compatible with the user experience provided by the agent service.
 * Architecture MUST support applications on a desktop or mobile device other than a browser; initial development efforts MAY not.
 * MAY support existing specifications and protocols such as WS-Federation, OpenID, SAML and IMI
 * MAY be used to provide claims used for authentication
 * MAY include the ability to provide current or past claims (and convey which is which)
 * MUST enable the exchange of variable claims which means that in some scenarios the process of retrieving claims-sets includes additional parameters that indicate something about the context of the request

Scope

 * To create a verified claims agent development community that includes open source, research and commercial efforts.
 * To build liason relationships with related efforts at OpenID Artifact Binding WG, IETF (e.g., OAuth), Kantara (e.g. ULX and CI), Mozilla (e.g. Account Manager) and W3C (new initiatives being considered). Where possible to work with these organizations on their respective specs, rather than creating new specs.
 * To build and test together at least one complete implementation of all claims agent components, including multiple cloud hosted agents and components for a wide range of desktop and mobile devices (specific systems and versions support TBD). May be a mix of open source and commercial components. The binaries of the commercially developed components must be available under RANDZ terms.  All desktop and mobile device components must be compatible with all of the cloud agent instances.
 * To fund one complete, open source claims agent implementation including a cloud agent (e.g., in either Java, or .NET, or other suitable language) and components for desktop and mobile devices. All open source code will be licensed under TBD license (most likely Apache 2.0) and resulting components must be interoperable with any commercially developed components.
 * To support and fund interoperability testing of claims agent components developed by the working group
 * To participate in discussions on: Trust frameworks that support the verified claims agent; relevant changes in laws and regulations; feedback from members of the privacy community.
 * Ensure that the architecture and all components developed enable expansion of the initial target scenarios to include commercial sources of claims, claims orchestration and aggregation, and claims marketplaces (where there may be transaction costs per claims exchange).
 * Consider how the architecture and components developed can enable value added services on both the cloud agent and the desktop and mobile devices.

Initial Target Scenario Characteristics

 * Claims come from government, health and education sources and are verified by some source-dependent means.
 * The expectation is that there is no cost to the citizen to use the claims and very limited cost, if any, to the organizations who consume them.
 * Supported RPs include those at the same institutions that provided the claims, different agencies at different levels of governments and across national borders, as well as commercial organizations.
 * Claims are exchanged in a way that helps protect the privacy of the citizen and security requirements of the claims provider (specific mechanisms employed depend on the scenario).
 * Support for authentication would be limited to pre-allocated identifiers such as email (i.e., not dynamically allocated pseudonyms)

Principles
See Identity Commons Purpose And Principles

Practices

 * We plan to collaborate using an Identity Commons-hosted mailing list
 * We plan to contribute source code to a common repository. This repository will likely be a new repository in a larger effort such as Outercurve Foundation or Eclipse.
 * We plan to collaborate with the Identity Commons OSIS WG for interoperability testing.
 * Specifications to be standardized would be submitted to standards groups such as OASIS, W3C, IETF and OpenID.
 * We plan to seek corporate funding for the open source code and interoperability phases of this work. As Identity Commons evolves to support directed funding, this funding will eventually be to Identity Commons and, after an overhead fee is extracted, the balance pass to this working group.

Requirements of Participation and How to Join
To be written

Licenses and/or Restrictions on Usage of Work Product

 * Open Web Foundation for specs
 * TBD: likely Apache 2.0 for code

Current Deliverables and Milestones
To be determined.

Current Meeting Schedule
To be determined.

Current Membership
This group has been proposed by Paul Trevithick. The following people have indicated interest in participating:


 * John Bradley
 * Iain Henderson
 * Mike McIntosh
 * Susan Morrow
 * Sandy Porter
 * Mary Ruddy
 * Don Thibeau
 * Paul Trevithick
 * Craig Wittenberg
 * Michael Versace

Current Stewards Council Representative and Alternate
The stewards council representative will be selected by the members of the working group.

Current Links
None at present.

Related Groups

 * OpenID Artifact Binding Working Group
 * Kantara ULX WG and Consumer Identity WG
 * Mozilla Account Manager
 * OpenInfoCard
 * FC2
 * Higgins Cloud Selector
 * Higgins Active Client

History
This is where the group can share about how/why the group was founded and where will be where quarterly reports will be linked to.