Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 in government, commercial industry, and higher education in 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.


Identifying Requirements for Attribute Management

http://kantarainitiative.org/confluence/display/AMDG/Attribute+Requirements

...

Anchor
gapAnalysis
gapAnalysis

Gap Analysis

As the group discussed requirements, identifying where those requirements had no cohesive, supporting effort behind them guided the definition and prioritization of gaps in the Attribute Management space. Some areas had limited work associated with them, but the effort behind that work either addressed only a small section of the problem space or seemed to be working in a vacuum. The list below highlights the major gaps and what work, if any, is happening in that area.

...

Gap #1: Attributes

Info
titleDefinition: 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"


It should be noted that Identity Attributes are part of, but not necessarily the complete set of, the Attributes associated with an 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. While this document takes a high-level, broad look at the attribute management space, finding information on all the activities and common definitions in this space to any kind of detailed level was impossible. 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, but pulling together 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.

...

Gap #2: 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 to understand industries and their associated activities that drive services,  and develop a classification system for and develop a classification system for the processes underlying the activities. 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 the sets of attributes that are managed down in the bowels of these generic processes.

Example:
While Enterprise Architecture Frameworks like the US FEAF (and the Australian and NZ EAF's are based on the US FEAF) segment down to Services and Functions, there is no work going 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 servicesfacing services,  the the process patterns supporting those services can be distilled down to: Grant, Register, Monitor, Advise, Enforce, Legislate, Collect.

...

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

Info
titleDefinition: 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

...

Common Semantics and terminology

A 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 be published to a central URN/URL namespace repository so other parties and metadata interoperating with the attribute provider can get the applicable 'set'.

...

The local definition of attributes in any given global schema, the interpretation of metadata and trust frameworks,  creates creates a space where it is very difficult to share information that will meet the expectation of relying parties.

...

Context

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 almost certainly vary according to the context in which it is requested or presented. An identity is expressed differently with different attributes under different contexts.

Info
titleDefinition: 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.   -- taken from the Government of British Columbia Identity Information Reference Model

...

Common language - Schema and Metadata

Attribute metadata is another aspect of attribute management concerning the concerning the exchange of attributes. What is needed is agreement on what the semantics are for metadata. 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

NOTE: Check with John Bradley/OASIS Trust elevation TC regarding where SAML is, and is notis not, relevant to this reportthis report.  

Efforts in this space:

Higher Education

...

  • ISO 21091:2011 Health Care LDAP schema

Commercial

  • OIX  (Attributes Exchange (AX) working group

...

Query Language

With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. 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.

...

  • OpenID Connect
  • SAML Attribute Query (profiled)?

Protocols

The protocol space around attributes is comparatively stable. Protocols such as SAML and OAuth are in broad use and fairly well understood. 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 fashion. In particular, how to use these protocols in the mobile device market is an issue.

...

  • SAML
  • OAuth
  • PKI certificates
  • OASIS Web Services over SOAP

Trust frameworks

With regard to attribute management and governance in Trust Frameworks, quite a bit of work has gone into the Identity Confidence/Assurance aspect, with different levels of confidence/assurance certifications described by different standards bodies, auditors trained, and a general understanding of the concept shared. That said, finding a trust framework that extends down to the level of the attributes themselves is still a work in progress . An individual could have a mix of self-asserted 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. The question of how a cohesive Trust Framework could handle could handle information at the attribute level is still an open question and will be a critical component of attribute management.   The complexity of attribute management is multiplied many times in the case of inter-federation. Trust framework governance framework governance becomes a critical dependency for cohesive attribute management.

The notion of levels of assurance applying to attributes has been to attributes has been recently challenged (see see http://blog.idmanagement.gov/2012/03/to-loa-or-not-to-loa-for-attributes-not.html  ) since the measure of confidence/level of confidence one can have in an attribute (and how that is determined)  is is likely to be different than the generally the generally understood notion of Level of Assurance which derived which derived from the context of OMB -04-04 and NSIT SP-800-63.  Work Work needs to be done to resolve to resolve any further confusion or misunderstanding through defining the components that constitute this this 'LoC', and to and to confirm the need to differentiate this context from the context of identity proofing and credential strength that strength that is applied to 'LoA' of identity. 

Efforts in this space:

...

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

...

Recommendations

Coordination

A more detailed review of working groups, standards efforts, and general understanding of terms is required.  The The ideal document would be