Abstract

The goal of the Attribute Management discussion group 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 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 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 Discussion Group includes a repository of links to information related to attribute management in government, commercial industry, and higher education in 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 Spaceattribute 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 schema and Metadatametadata
• Agreement on a standard query Languagelanguage
• 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

It should be noted that Identity Attributes Depending on the definition identity attributes are part of, but not necessarily the complete set of, the Attributes attributes associated with an a subject or individual. Each Identity Proofing identity proofing process needs to establish the set of Identity Attributes 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 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, but pulling together 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 discussing specific industry classifications and activity classifications. More work is needed, however, to understand industries and their associated activities that 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 processes underlying the activitiesthese. For interoperability, we need an agreed upon taxonomy, syntax, grammar and semantics for these process patterns just as much as we need the agreement for on the sets of attributes that are managed down in the bowels of these generic processes.

Example:

While Enterprise Architecture Frameworks (EAFs) like the US Federal Enterprise Architecture Framework (FEAF) (and the Australian and NZ EAF's are based on the US FEAF) segment down to Services services and Functionsfunctions, 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.Each   Can these descriptions be standardised and can the same be done for each of these functional process patterns contains sub-sets and super-sets of attributes. ?

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

Efforts in this space:

• SEMIC.EU was a starter project but closed in 2009, now partly replaced by ISA
• The Government of Canada strategy of federating credential and then federating identity 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 code lists and meanings to a public directory should be possible. There is a need for local profiles to Local profiles could be published to a central URN/URL namespace repository so other parties and metadata interoperating with the 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 released available and provide an audit trail.

The local definition Local definitions of attributes in any given global schema , along with the interpretation of related metadata and trust frameworks , creates a space situation where it is very difficult to efficiently share (or trust) information that will .  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 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 semantics and Terminologyterminology, 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.

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? attribute semantics, governance, schema? It overlaps all of the abovethese.

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 another 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

...

• 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)
• Relevant??: 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 broad 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 a secure and interoperable an interoperable (and secure) fashion. In particular, how to use these protocols in the mobile device market context is an at issue. In addition, a   A means is needed to ask a broad set of identity providers anything about the identities 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 answer.easy path to accomplish this.

Efforts in this space:

• SAML
• SAML Attribute Query (profiled)?
• OAuth
• PKI certificates
• OASIS Web Services over SOAP
• OpenID ConnectSCIM
• 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, quite a bit of trust frameworks, substantial work has gone into the Identity Confidence/Assurance aspect, with different identity confidence/assurance.  Different levels of confidence/assurance and associated certifications are described by different standards bodies, auditors trained, and a general understanding of the concept sharedaccreditation 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 the level of the attributes themselves a widely useful set of attributes is still a work in progress. An individual could 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 could handle information handles confidence at the federated attribute level (perhaps outside of higher education) is still an open question and will be .  This gap and open question is a missing and a critical component of attribute management in practice. The complexity of This attribute management gap is multiplied many times in the case of inter-federation context. Trust framework governance becomes a critical dependency for cohesive 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 ) since   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 generally understood notion of manner in which Level of Assurance which is derived from the context of OMB M-04-04 and NSIT 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', and to confirm .  There also exists the need to differentiate this context from 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 still 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 UXuser 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 overlap intersection of financial reward and privacy regulation; overlaps situations such as this generally see the creation of some kind of governance model. That governance may be formal regulation, it may be 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 "identify 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 entity 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 entity identity attributes, or sets of entity 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 entity identity attribute or a set of entity identity attributes.

• Recommendation: Creation of a Kantara Attributes Attribute Management Working Group or continuation of the existing Discussion Group (but rechartered) to work with across industry organizations and sectors.  Work to recommend establish a means of expressing relying party needs with respect to a level of confidence in an entity identity attribute, or a set of entity 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.