Page Comparison

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

...

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

...

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

...

• 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?

...