Kantara Consumer Identity WG Teleconference
Date and Time
- Date: Tuesday, April 6, 2010
- Time: 9 PDT | 12 Noon EDT | 5 PM UK | 1600UTC
- Call-in Info: Skype: ++9900827044630912
US/Canada Dial-In: +1-201-793-9022 | Room Code: 4630912
UK +44 (0) 8454018081
- Jeff Stollman
- Bob Pinheiro
Continue discussion towards defining a proposal for WG funding. Our ultimate goal is to help understand the requirements and criteria for deployment of an identity infrastructure that can support the needs of consumers. Three components of such an infrastructure are:
- Open identity technologies such as OpenID and Information Cards.
- Trust frameworks that can enable trusted identity transactions between Identity Providers issuing OpenIDs or Information Cards, and Service Providers/Relying Parties relying on assertions/claims issued by these Identity Providers.
- Strong authentication technology to be used by consumers to authenticate to their Identity Providers.
Perhaps most importantly, whether such an infrastructure comes into being seems to depend on:
- whether Service Providers / Relying Parties will perceive a need for the kinds of identity-related assertions or claims enabled by OpenID and Information Cards,
- whether consumers can be educated and made aware that such an identity infrastructure can protect them against identity fraud,
- whether Identity Providers that issue OpenIDs and Information Cards, as well as the assertions associated with these, will have a business justification for doing so.
The trust frameworks (Kantara IAF and Open Identity Exchange (OIX) ICAM TF ) defined so far are geared to supporting the specific needs of US government RPs. The is because the US government has stated its requirements for trust frameworks that enable the use of open identity technologies for access to government services under the government's Open Identity Initiative.
However, a trust framework is ultimately useful only if the identity assertions from IdPs to RPs support the identification / authentication needs of specific RPs. Since these needs may be different for non-government RPs, other "trust communities" of relevance to consumers might also need to exist. Such trust communities might include financial services, healthcare services, and personal data or information-sharing services, for instance.
With these things in mind, a funded WG project might focus on one or more of the following:
- Identify trust communities of special relevance to consumers that may have needs for trust frameworks different than the currently defined ones geared to the US government. Work with members of these trust communities to define such trust frameworks.
- Work with members of different trust communities to better understand, or help define, requirements for OpenIDs and Information Cards that can support the needs of consumers who obtain identity-dependent services within these communities.
- Understand the usability of various forms of strong authentication to be used by consumers to authenticate to their IdPs. One issue in particular is whether consumers would want to use the same authentication method across all trust communities that they participate in, or whether authentication methods would more likely depend on characteristics of consumers obtaining services within each trust community. In other words, even if consumers use different Information Cards or OpenIDs for online access to their financial institutions and their healthcare providers, can they use the same authentication method (one-time passwords, PKI browser certs, PKI certs on USB tokens, etc.) when authenticating to their IdPs that issue assertions?
This encompasses a wide range of possible activities. I'd like to discuss these with the WG to help determine priorities and viability in terms of resources that might be needed to accomplish these goals, as well as who might be potential funders. As I've previously said, I'm making the assumption that most, if not all, of the work involved with such a project would be performed by entities that would receive funding, and that WG members would act mainly as overseers and reviewers who might also be able to contribute their own insights where appropriate.
Because only one other participant showed up, discussion was deferred to a later time.
- Date: Day, Month Day#, Year#
- Time: X PDT | X EDT | X UTC (Time Chart)
- Dial-In: \
NOTE: Do not follow the code with a "#" symbol as it may cause the code not to be recognized.