Abstract

The goal of the Attribute Management Discussion Group is to determine what Attribute Management means to Kantara Initiative (KI) stakeholders, what areas need further discussion or development, and to make recommendations regarding where and how the Kantara Initiative should contribute to efforts in this space.

The charter states:

IDENTIFY: Kantara Initiative stakeholder requirements regarding Attribute Management.
GAP ANALYSIS: Attribute Management KI stakeholder requirements compared to work under development (both internal and external to KI)
RECOMMEND: scope of work, potential KI adoption of external works, collaboration with external organizations and/or new WG in KI to perform design phase of Attribute Management based on requirements, discovery and gap analysis.

The purpose of this report is to provide a high-level look at the current state of the Attribute Management space and make recommendations on where further work would provide the most value to KI stakeholders.

Introduction

Note: the full charter of the Discussion Group is available online

With a variety of government, commercial, and research initiatives around Internet Identity, the questions around if and how to create a common methodology for managing the bits of information about an entity on the Internet is in need of answers. The Kantara Initiative has sponsored a Discussion Group to look at the attribute management space and make recommendations on where focused effort from the Kantara Initiative might help move this space forward. While attributes can apply to both individuals and devices the work here is focused on human (identity) attributes.

This report and associated recommendations have been developed out of several months of reviewing and discussing the attribute space across a broad range of sectors and interests. The wiki space for the Discussion Group includes a repository of links to information related to attribute management in government, commercial industry, and higher education from sources including the United States, Canada, Europe, and New Zealand. From that base of information we have identified the following gaps and made a set of recommendations for further work.

Gap Analysis

During the work conducted by the Discussion Group it identified areas that it believed had no cohesive, supporting effort behind them. Analysis of these areas identified the following gaps in the Attribute Management space:

Definitions in the attribute space
Identification of common core business activity (and matching process) sets
Establishing common semantics and terminology
Identification and definition of contexts
Agreement on a common language - schema and metadata
Agreement on a standard query language
Interoperability between protocols
Trust frameworks
Defining and implementing consent
Governance around use of attributes

The following elaborates each of these gaps including the work, if any, that Discussion Group members were aware was happening in the area.

Gap #1: Terminology in the attribute space

Definition: Identity Attribute

Information bound to a subject identity that specifies a characteristic of the subject. – Derived from the ITU-T X.1252 definition of "attribute"

Depending on the definition identity attributes are part of, but not necessarily the complete set of, the attributes associated with a subject or individual. Each identity proofing process needs to establish the set of identity attributes it deems necessary and sufficient to infer, with a level of assurance, who an individual is (i.e., the identity of the individual) based upon the risk / consequences of being incorrect. The Discussion Group agreed to use the above as a working definition, but there was enough discussion and confusion regarding whether or not this was sufficient to make this the first identified gap in the attribute management space.

The repository of information put together by the Attribute Management Discussion group is a start to closing the gap around the definitions required of the different components of the attribute ecosystem. Investigating the creation of a more granular document should be a fundamental requirement to further work being done by Kantara. The general consensus is that it is better to take the time to find where work is going on than to duplicate effort. The monitoring and coordination of efforts across the attribute management space is a general theme among the gaps and recommendations.

Efforts in this space:

Kantara Initiative Attribute Management Discussion Group – Industry Efforts wiki page: http://kantarainitiative.org/confluence/display/AMDG/Current+Industry+Efforts
Internet Society Trust & Identity group, Mapping the Identity Ecosystem and Moving Forward with an Internet Attribute Infrastructure workshops (reports not yet public)

Gap #2: Identifying common core business activity (and matching process) sets

Discussions around attribute management extend into specific industry and activity classifications. More work is needed, however, to understand if it is possible to describe across industry a core set of activity and processes that drive services, and develop a classification system for the these. For interoperability, we need an agreed upon taxonomy, syntax, grammar and semantics for these process patterns just as much as we need agreement on the attributes that are managed down in these processes.

Example:

While Enterprise Architecture Frameworks (EAFs) like the US Federal Enterprise Architecture Framework (FEAF) (the Australian and NZ EAF's are based on the US FEAF) segment down to services and functions, there is no work going on to standardise the terms to describe generic business process patterns. For example, in the NZ government's Internal Affairs Department's public facing services the process patterns supporting those services can be distilled down to: Grant, Register, Monitor, Advise, Enforce, Legislate, Collect. Can these descriptions be standardised and can the same be done for each of these functional process patterns sub-sets and super-sets of attributes?

In addition, there is a need to understand the needs of service providers that rely upon identity attributes in order to deliver services. An understanding of relying party needs will help drive the definition of the process and procedures that need to exist to provide assurances about an identity attribute or a set of identity attributes. It will also drive the definition of the criteria required to enable organizations to become an authoritative party for an identity attribute or set of identity attributes.

Definition: Authoritative Party

An organization or individual that is trusted to be an authority on the identity related attributes or roles associated with users and subjects of services. -- taken from the Government of British Columbia Identity Information Reference Model

Efforts in this space:

SEMIC.EU was a starter project but closed in 2009, now partly replaced by ISA
Federating Identity Management in the Government of Canada: A Backgrounder
North American Security Products Organization (NASPO) http://www.naspo.info/PDFiles/IDPV_PBP_WorkProgressReport.pdf

Gap #3: Normalization and categorization of identity attributes

A broad, common, accepted list of attributes and associated definitions is currently not achievable in its entirety. The goal, however, of publishing lists and meanings to a public directory should be possible. Local profiles could be published to a central URN/URL repository so other parties and metadata interoperating with an attribute provider can get the applicable 'set'.

Consider a common structure for 'attributes of an attribute' - the properties of an attribute (e.g. unique, authoritative or self reported, time since verified, last time changed, last time accessed, last time consented) that would be available and provide an audit trail.

Local definitions of attributes in any given schema along with the related metadata and trust frameworks creates a situation where it is very difficult to efficiently share (or trust) information. This gap needs to be addressed in a context that can meet the expectation of relying parties working across identity and attribute providers.

Efforts in this space:

InCommon Federation site regarding the Categorization of attributes
The Finnish attribute profile (in Finnish but English option available of the portal front page): http://www.suomi.fi/suomifi/tyohuone/yhteiset_palvelut/verkkotunnistaminen_ja_-maksaminen_vetuma/tekninen_rajapinta/finnish_attribute_profile/FinnishAttributeProfile20110221.pdf
UK government data standards http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/e-gif/datastandards.aspx
An emerging effort is the ISOC initiative 'Moving forward with an Internet Attribute Infrastructure', that spawned from the main gap identified in the 2011 workshop 'Mapping the Identity Ecosystem' ( http://tid.isoc.org/trac/ideco) ;

Gap #4: Identifying and defining contexts

Perhaps a subset of semantics and terminology, the question of context is significant in its own right. From an electronic identity perspective, what information is expressed about an individual will often vary according to the context in which it is requested or presented. An identity is expressed differently with different attributes under different contexts.

Definition: Identity Context

The environment or circumstances in which identity information is communicated and perceived. Individuals operate in multiple identity contexts (e.g., legal, social, employment, business, pseudonymous) and may identify themselves differently based on the context. -- taken from the Government of British Columbia Identity Information Reference Model

Different contexts may include:

individual as citizen
individual as social group member
individual as employee
individual acting in a business role e.g. Director
individual as researcher, student, or faculty

How should identity attributes be categorized or expressed in different contexts? Are these different identity attributes or sub-attributes? Is this a question that can be rolled in to the questions around attribute semantics, governance, schema? It overlaps all of the these.

Efforts in this space:

The Government of British Columbia evidence of identity
New Zealand Evidence of Identity Standard and additional guidance

Gap #5: Agreeing to a common language - Schema and Metadata

Attribute metadata is an aspect of attribute management concerning the exchange of attributes. What is needed is agreement on what the semantics are for metadata. For example, SAML has some metadata for attributes, but much more will be needed as the growth of interoperability of attributes continues. We will need registries for attribute sets/categorization (i.e. IANA), agreement about the semantics, and mappings between sets of attributes having differing semantics

Efforts in this space:

Higher Education

the eduPerson schema
the SCHema for ACademia effort (SCHAC) – Europe

Health Care

ISO 21091:2011 Health Care LDAP schema

Commercial

OIX (Attributes Exchange (AX) working group
Simple Cloud Identity Management(SCIM)

Government

Finland's Suomi.fi
British Columbia, Canada attributes about people and their relationships with others in a government context and an initial set of attributes or claims
Austria's eGov-cooperation /local/state/federal): Specification of "eGov token" (pdf, German)
UK government Data standards http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/e-gif/datastandards.aspx

See also others in Repository [Current Industry Efforts|]

Gap #6: Interoperability between protocols

The protocol space around attributes is comparatively stable. Protocols such as SAML and OAuth (and related OpenID Connect and User Managed Access (UMA) are in use and fairly well understood even if they are still evolving. PKI certificates and web services also have strong community support and understanding. What is missing, however, is better guidance on how exactly to use those protocols to carry attributes and their associated metadata in an interoperable (and secure) fashion. In particular, how to use these protocols in the mobile device context is at issue. A means is needed to ask a broad set of identity providers about the wide range of attributes for which they are authoritative or trusted. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?" the attribute space has no easy path to accomplish this.

Efforts in this space:

SAML
SAML Attribute Query
OAuth
PKI certificates
OASIS Web Services over SOAP
OpenID Connect
SCIM
United States Federal Identity Credentialing and Access Managment (FICAM) profiles

Gap #7: Trust frameworks

With regard to attribute management and governance in trust frameworks, substantial work has gone into identity confidence/assurance. Different levels of confidence/assurance and associated certifications are described by different accreditation and standards organizations. Auditors have been trained and are at work across these organizations but these do not fully address the accreditation needs around attribute management. That said, finding a trust framework that extends down to a widely useful set of attributes is still a work in progress. An individual can have a mix of self-asserted, derived and proofed attributes describing them, and a consumer of those attributes should be able to choose which attribute to use, depending on the context of the activity or transaction and have knowledge about how the attribute was established. The question of how a cohesive Trust Framework handles confidence at the federated attribute level (perhaps outside of higher education) is still an open question. This gap and open question is a missing and a critical component of attribute management in practice. This attribute management gap is multiplied in the inter-federation context. Trust framework governance becomes a critical dependency for attribute management and is a challenge today across identity and attribute providers.

The notion of levels of assurance applying to attributes has been recently challenged (see http://blog.idmanagement.gov/2012/03/to-loa-or-not-to-loa-for-attributes-not.html ) and as a result the DG has also adopted the use of the term level of confidence. Since the measure of confidence/level of confidence one can have in an attribute (and how that is determined) is likely to be different than the manner in which Level of Assurance is derived from the context of OMB M-04-04 and NIST SP-800-63-1. Work needs to be done to resolve any further confusion or misunderstanding through defining the components that constitute this 'LoC'. There also exists the need to compare and contrast this with the context of identity proofing and credential strength that is currently applied to the 'LoA' of identity.

Efforts in this space:

OIX Attribute Working Group
Kantara's Business Cases for Trust Frameworks: http://kantarainitiative.org/confluence/display/bctf/Home
ProtectNetwork: www.protectnetwork.org
United States Federal Government Backend Attribute Exchange

Gap #8: Defining and implementing consent

The legal definition and implementation around consent is reaching a stable point in the EU. That said, there is still some concern that implementing consent in the federation space is problematic. Consent management will undoubtedly involve consent-related attributes and attribute sets in the consent process. Consent needs to be 'designed in' either as in band or as a service but implemented in a standardized way so you get consistent user experience. Consent is also important when examining the use of attributes.

Efforts in this space:

EU Data Protection
ABC4Trust: https://abc4trust.eu/
Kantara Initiative P3WG Privacy Assessment Criteria
Kantara User Managed Access (UMA) Working Group

Gap #9: Governance around use of attributes

A driver for the exploration of attribute management is the growing economy behind the mining and exchange of attribute information. We see here the intersection of financial reward and privacy regulation; situations such as this generally see the creation of some kind of governance model. That governance may be formal regulation, accepted industry standards groups, or some other model. Different sectors of society and industry are looking at what governance is necessary in the world of Internet Identity and the attribute economy. Each group, however, has a fairly narrow view of how governance is required in their particular sector. The definition of governance needs to identify the extent to which consent is required.

Efforts in this space:

Federal PKI and PKI Bridge Certification Authority: http://www.idmanagement.gov/
APEC Privacy Framework, in particular the Cross Border Privacy enforcement Arrangement: www.apec.org/Groups/Committee-on-Trade-andInvestment/Electronic-Commerce-Steering-Group/Cross-border-Privacy-Enforcement-Arrangement.aspx
An emerging effort is the ISOC initiative 'Moving forward with an Internet Attribute Infrastructure', that spawned from the main gap identified in the 2011 workshop 'Mapping the Identity Ecosystem' ( http://tid.isoc.org/trac/ideco )
Open Identity Exchange
NSTIC (potentially)

Recommendations

Recommendation #1: Defining Contexts

In response to Gap #3, 4, 5, and 6

One of the common themes found throughout the gaps identified in the attribute management space involved context. Everything from the definition of "identity attribute" to defining appropriate trust frameworks depends on the context in which the information is to be used. With a stronger understanding and implementation of the idea of context, the questions of automatically identifying risk and liability may be answered appropriately for all the different constituents involved in the attribute ecosystem. The normalization of language around attributes can be handled more effectively when contexts are defined and identified. Contexts turn out to be the most fundamental organizing principle in the attribute management space.

Recommendation: Create a Kantara Discussion Group (or subgroup of a Working Group) to describe what contexts might be and how they might be used, characterizing them and registering/exposing them.

Recommendation #2: Clarifying the use of attributes

In response to Gaps #2, 8, 9

There needs to be effort around understanding how identity attributes will be used by Relying Parties and the criteria that need to be in place to allow Relying Parties to trust in the identity attributes, or sets of identity attributes, they receive. An understanding of these needs will drive the definition of the mechanisms that will need to exist to provide assurances about an identity attribute or a set of identity attributes.

Recommendation: Creation of a Kantara Attribute Management Working Group or continuation of the existing Discussion Group (but rechartered) to work across industry organizations and sectors. Work to establish a means of expressing relying party needs with respect to a level of confidence in an identity attribute, or a set of identity attributes.

Recommendation #3: Definitions and general coordination

In response to Gap #1

A more detailed review of working groups, standards efforts, and general understanding of terms is required. The ideal document would be “Attribute Management and The Attribute Ecosystem--The Players, Their Work, The Issues”. There needs to be effort around the normalization of a base identity attribute set. While we see work going on in the FICAM, OASIS, SCIM, OIX-AX and other arenas, work still needs to be done to bridge those and any other efforts together to make a cohesive attribute set.

Recommendation: Creation of a Kantara Attribute Management Working Group or continuation of the existing Discussion Group (but rechartered) to conduct an environmental survey of groups and activities in the attribute management space (there are dozens at least) and create a cohesive index and description of where they fit in the attribute management space, where they are orthogonal or overlapping (this should be a prerequisite to the attribute LoA/LoC work mentioned below under 'Trust Frameworks')
Recommendation: Establish formal liaison with the OIX Attribute Exchange Working Group and the OASIS Trust elevation Technical Committee so that the various efforts are harmonised, synergistic and do not overlap.

Recommendation #4: Query Language

In response to Gap #6

While the need for a query language that could handle multiple schemas and protocols is identified as a gap by this discussion group, closing that gap was determined to be outside the mandate and expertise of the Kantara Initiative. This area should be left to other organizations, such as OASIS, IETF or the W3C.

Recommendation #5: Trust frameworks

In response to Gap #7

Current trust framework/federation/circles of trust deployments are still developing their approaches to attribute management. Interfederation increases the complexity of attribute management many times. In the case of inter-federation, trust framework governance becomes a critical dependency for cohesive attribute management.

Recommendation: Create a Kantara Working Group or co-create/collaborate in the creation of a group elsewhere (IDCommons, ISOC, OIX - wherever most support can be garnered) to define the components that constitute a 'LoC' for attributes and to confirm the need to differentiate this context from the context of identity proofing and credential strength that is applied to 'LoA' of identity. The output of this work should be submitted to an SDO for onward standardization, to avoid any future confusion or misunderstanding.
Recommendation: Monitor developments in ISOC's 'Internet Attribute Infrastructure' initiative, the Business Cases for Trusted Federations (BCTF) DG, and look for opportunities to develop specific work streams within Kantara. (One potential area is to create a Kantara Working Group to establish an LoC/LoA program and associated criteria for attributes. Kantara has experience in providing and vetting an LoA framework for identity with the Identity assurance Working Group and the Assurance Review Board; can that be expanded in to providing LoC/LoA for attributes?)

Recommendation #6: Governance

In response to Gap #8, 9

The governance aspect of attribute management is critical - both inwards facing from a trust framework/federation/circle of trust down to and through the enterprise, and outwards to global governance of accessible repositories of attribute sets. While there are sporadic efforts in communities at present, what is needed is a commonly agreed roadmap to further develop attribute management and a set of guidance and best practice to assist implementers and deployers.

Recommendation: Kantara establish multiple liaisons with the ISOC 'Internet Attribute Infrastructure' initiative back to the AM DG (or a sub group of the proposed AM WG Group) and the BCTF DG, and monitor progress for specific work streams to be developed within Kantara.

Recommendation #7: Mechanisms

In response to Gap #8

The mechanisms required to enable discovery, maintenance and exchange of identity attributes are critical to deploying identity solutions. These mechanisms must address the security and privacy concerns of subjects, relying parties and identity providers both within and across trust frameworks.

Recommendation: Creation of a Kantara Attribute Management Working Group or continuation of the existing Discussion Group (but rechartered) to make recommendations concerning catalogs of vertical specific attribute sets (i.e. extensions), lists of authoritative sources for attribute sets, protection and sharing of attributes (including privacy), and the metadata used to describe attributes.

Glossary

As pointed out definitions are still a gap around attribute management, that notwithstanding the following references have been used in the development of this report. In addition to the way terms are defined in the Kantara Initiative Identity Assurance Framework Glossary the report also uses the following terms and definitions:

Authoritative Party - An organization or individual that is trusted to be an authority on the identity related attributes or roles associated with users and subjects of services.

Identity Attribute - Information bound to a subject identity that specifies a characteristic of the subject.

Identity Context - The environment or circumstances in which identity information is communicated and perceived. Individuals operate in multiple identity contexts (e.g., legal, social, employment, business, pseudononymous) and may identify themselves differently based on the context.

Browser not supported