AIMWG telecon Notes 2012-11-27

Date and Time

• Date: Tuesday, 27 November, 2012
• Time: 13:00 PT | 16:00 ET | 21: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. Call for Nominations: Chair, Vice-Chair, Secretary
   4. Call times
2. Discussion
   
   1. Charter Review: http://kantarainitiative.org/confluence/x/GAGgAw
   2. Relationship with REFEDs
   3. Work items:
      
      1. Specifically, the Work Group will create a set of best practice documents around:
         
         1. The handling of attributes by Identity Providers, Relying Parties, and Service Providers
         2. The definition and proposed use for contexts
         3. The definition, best use, requirements and criteria of an Attribute Broker
      2. Repository maintenance: AMDG Repository
3. AOB
4. Adjourn

Attendees

• Allan Foster
• Steve Olshansky

Non-Voting

• Ken Dagg
• Bob Sunday
• Karen O'Donoghue
• Ken Klingenstein

Staff

• Heather Flanagan (scribe)

Apologies

• call not at quorum

Minutes

Administration

• Call for Nominations: Chair, Vice-Chair, Secretary

• Call times
  
  • Calls will be bi-weekly; may change as further input is received from the group and a doodle poll created; for immediate purposes, we will have our next call in 2 weeks at this time

New Action Items

Discussion

Charter Review: http://kantarainitiative.org/confluence/x/GAGgAw

• Looks good, and particularly interested in the Attribute Broker work

Relationship with REFEDs

• See the work plans started on the REFEDs list: https://refeds.terena.org/index.php/REFEDS_Planning_Documents_2013
• group want to liaise with the AIM WG; Allan to contact Ken Klingenstein to discuss document sharing and coordinated work effort; Steve Olshansky to also help act as liaison to those work efforts
• Description from Ken on the work effort:
  • I2/InCommon have an NSTIC grant "Scalable Privacy" - one aspect of this grant is the implementation of anonymous credentials in the attribute ecosystem (see ABC4Trust model); it is around gaps from getting that technology deployed in the real world.  How does the anonymous credential move from the attribute authority to the IdP that holds it on behalf of the user while remaining anonymous?  This leads to account linking and privacy concerns, attribute providers versus attribute authorities, and more.  How can attributes move?  We don't even have a reference model for the life-cycle of attributes, possibly not even sufficient terminology.
  • Looking for the right place(s) to have this conversation to come up with answers, a gap analysis, etc.
  • This space has enough rat holes and yet is such a real set of problems, need to figure out how to get these things moved as opposed to stuck in rat holes.  Need urgency.
  • One of the things missing in this area is a clear problem statement on what EXACTLY needs to be solved.  If we don't know what problem we are solving for, we see a wide variety of solutions to things that aren't exactly the same set of problems.
    
    • brought this up to ABC4Trust to ask how they would handle releasing anonymous credentials, and after discussion they stated that that determining how a user could get those released was out of scope for them; they are more focused on crypto
    • true goblin in all this space is LoA of attributes; a rat hole that needs partitioning to name the rats.  What does LoA of attributes even mean?  Would we do better to look at the lifecycle of an attribute?
  • There is an NSTIC Scalable Privacy graphic that starts to list out all the players in this space and which may at least name some of the areas that the AIM WG might be interested in (attached to these notes; note that an Attribute Verifier is an entity that needs to be added to that picture)
    
    • if we could look at that and determine what is in scope and out of scope would be helpful
    • another challenge is to put together a list of definitions regarding the things on that diagram
      
      • any one real-world entity might actually be parts of several different items on that diagram, so maybe trying to tightly define each is not actually all that useful; what about trying to approach this from a possible lifecycle perspective?  group things based on whether they fall in the origination of an attribute?
        • Heather/Ken to put together a rough list of definitions regarding those entities in that diagram
      • would like to capture more than real-time exchanges, want to also capture batch processes
      • want to capture the transition from one state in the lifecycle to another; but that could be a bigger conversation than we have time for
        
        • the question of currentcy of an attribute and what triggers the change in currentcy, dependency change, that's part of the conversation of state transition that's important to know
    • trying to understand what it is we need to define seems to be at the heart of this conversation so far

Work items:

Specifically, the Work Group will create a set of best practice documents around:

The handling of attributes by Identity Providers, Relying Parties, and Service Providers

The definition and proposed use for contexts

The definition, best use, requirements and criteria of an Attribute Broker

• Consider adding a lifecycle of attribute document

Repository maintenance: AMDG Repository

• do not need to do anything much to it right time; when we get to the point of turning it to an active, working document again we will copy it (or maybe just the format) and roll in to our space

Any Other Business... Adjourn

Next Meeting

• Date: Tuesday, 11 December 2012
  
• Time: 13:00 PT | 16:00 ET | 21:00 UTC (Time Chart)
• Dial-in: United States Toll +1 (805) 309-2350
  
  •  Alternate Toll +1 (714) 551-9842
• Skype: +99051000000481
  
  • Conference code: 613-2898