AIM WG Minutes 07-August-2013

Date and Time

• Date: Wednesday, 7 August 2013
• Time: 07:00 PT | 10:00 ET | 14:00 UTC
• Dial-in: United States Toll +1 (805) 309-2350
  
  •  Alternate Toll +1 (714) 551-9842
• Skype: +99051000000481
  
  • Conference code: 613-2898

Agenda

1. Administration:
   
   1. Roll Call
   2. Agenda Confirmation
   3. Approval of Minutes:AIM WG Minutes 01-May-2013
2. Discussion / Action Item Review
   1. Attribute registry discussion (Keith)
   2. Further discussion of WG - Attributes In Motion - Roadmap Planning - AIMWG and assigning shepherds (assuming Ken Dagg and/or Colin Wallis are available)
3. AOB
4. Adjourn

Attendees

• Allan Foster
• Keith Hazelton
• Sal D'Agostino

As of August 5, 2013, quorum is 3 of 5

Non-Voting

• Maarten Kremers
• Ken Klingenstein

Staff

• Heather Flanagan

Apologies

• Steve Olshansky

Minutes

Approval of Minutes:AIM WG Minutes 01-May-2013

• Keith Hazelton moves to approve the minutes, Sal D'Agostino seconds - minutes approved with no objection

Administration

Action Items

New Action Items

Discussion

NSTIC IDESG and the Monolithic Trust Framework model

• would like to add to a future agenda a "periodic table of trust elements", as opposed to the monolithic trust framework being designed by the NSTIC IDESG
• would include what needs to be done to identity proof an organization, what do people normally consider to be trust framework, privacy issues, shared attributes
• Ken to work on this and hopes to have something for discussing by the next call; will need to figure out how to recast it in a more general audience

Attribute registry

• Keith: I have uploaded the current version of the identity attribute ontology to http://webprotege.stanford.edu. Look for "Identity Attributes" in the catalog of ontologies, then open to browse.

The following is not meant to be self-explanatory, it's just reference material for a discussion of attribute properties (aka attribute metadata)

 Attribute Ontology Classes:
 
 - Attribute
 - AttributeClass
 - Specification
 
 Properties of Attributes (simple values)
 - AttributeName
 - Definition
 - Oid
 - Syntax
 - SourceLocation
 - Section (within source)
 
 Relational Properties of Attributes
 - classifies (AttributeClass classifies Attribute)
 - isClassifiedBy (Attribute isClassifiedBy AttributeClass
 - specifies (Specification specifies Attribute)
 - isSpecifiedBy (Attribute isSpecifiedBy Specification)
 
 Proposed additional metadata elements:
 
 - Contextual relational properties of Attributes
 - AuthoritativeSource 
 - RelyingParty R considers the AuthoritativeSource of Attribute A to be Source S
 - AttributeProvider P considers SystemOfRecord S to be the AuthoritativeSource of values for Attribute A
 - ...
 
 - Contextual properties of Attributes
 - relational: (Attribute) isInBundle (B1)
 - ...
 
 - Operational properties of Attributes
 - LastUpdatedTimeStamp
 - LastUpdatedBy
 - ...
 
 Properties of Attributes in the Identifier AttributeClass
 - Persistence
 - Reassignability
 - IdentityRevealing
 - HumanPalatability
 - Uniqueness
 
 Reflections on the notion of a level of confidence (LoC) for attributes
 - is mostly contextual (between an attribute issuer and an attribute consumer/relying party)
 - "RP A assigns LoC X to attribute Y when provided by AttributeProvider Z"
 - is difficult to process dynamically

ABAC workshop, 800-162 - how attributes and access control tie together

• trying to determine language around metadata led to a very interesting discussion which this information could do quite a lot to inform

Discussion on metadata

• Note that all metadata information really must be considered in context
  
  • i.e., Level of Confidence involves the relationship between the consumer and provider
• previous iterations of this had not distinguished between identity revelaing and human palatability - this is a very useful distinction
• the issue of access control to attributes in LDAP came up during IETF week; the access control around attributes is an ephemeral, localized piece of metadata
  
  • that is generally defined by the admins of the LDAP, but in an UMA world, you may see this being defined per RP and is hugely relational and contextual and so it does become a useful piece of metadata
• in terms of scope, what about IdP revealing over identity revealing, either of which could violate some of the privacy principles; is there possibely a hybrid that would not be identity revealing but is scoped to just give hints?
• it would be worthwhile to see how other identifiers mapped into these characteristics, and suggest going with an identifier that is not a name (i.e., mobile number)
• note that the way forward from the NSTIC monolithic point of view is an attribute registry
• what do we even do with a Level of Confidence, unless the levels are well defined and the characteristics are define; even then, it really seems more like a binary operation - you either have confidence or you don't
  
  • it may be sufficient for the RP, but at the end of the day, it is either on or off
  • the idea that you could code that "46% or higher is ok" is fraught with trickiness
  • this could be used where people are talking about using attributes to enforce access control
  • the federal government has decided to deal with by creating one big flat list of attributes, and an attribute definition and name means one thing and one thing only
  • LoA of attributes being done by the Attribute Exchange Network - that's another perspective; Ken to send a copy of the slides describing that work
• Starting to deal with other use cases around First Responders; there are instances where your attributes will come from your IdP but they may have expired, however the person may still be the best person available to provide support in that area - there is a requirement for care that can override expired credentials; how would those use cases impact the metadata described?
  
  • that does reintroduce a temporal aspect in to the metadata
  • some part of the AXN type use cases, there may be instances where your physical address may have been specified a year ago, but actually what is really important is when was the last time it was used successfully; there are multiple concepts here that may be getting in to too much detail
    
    • the definition of "last", "use", and "successful" will be contextual based on the RP or the group of RPs; you can ramify this stuff infinitely, but one of the points we need to get across to people is that you will HAVE to specify the community that is talking about that concept or you will have no traction; someone has to maintain it, someone has to rely on it 
    • there is a theme of communities of interest and how they can scope down the plethora of meanings to some kind of specific meaning; some people will ask the federal government to step in to define One True Meaning (which is doomed to failure since there is no enforceability); maybe there is a piece of overarching meta-metadata that could address the points of confusion around what community is using this information
    • given context has overloaded meaning, maybe we should rephrase this in to "community of interest" or some other word that is less ambiguous? 
    • the difference community of interests that will work with these attributes will have very different needs; there are several ways we can try to approach that, including coming with an overriding document describing all use cases (probably an exercise of futility), we can leave all definitions up to said community of interest (which is dancing around the problem) or we can provide guidance to communities offering suggestions and pointing out challenges, guidelines to how to create identifiers, etc.
      
      • that should be the preface "to serve citizens" which is a deliverable for Keith and Ken as part of the NSTIC Scalable Privacy grant
      • how to get this in front of people before they make the expected mistakes?

Note that Ken Dagg and Colin Wallis are not available, so that topic will be moved to our next call

Next Call

• Date: Wednesday, 21 August 2013
• Time: 07:00 PT | 10:00 ET | 15:00 UTC
• Dial-in: United States Toll +1 (805) 309-2350
  
  •  Alternate Toll +1 (714) 551-9842
• Skype: +99051000000481
  
  • Conference code: 613-2898