AIM WG Minutes 09-Jan-2013

Date and Time

• Date: Wednesday, 09 January 2013
• Time: 07:30 PT | 10:30 ET | 15:30 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
2. Discussion / Action Item Review
   
   1. 2013 Roadmap
      
      1. Prioritization
      2. Discovery process for listed Recommendations
      3. Additional outreach and liaison statement
   2. Trust and Attribute flows (Ken Klingenstein) - see slides on Scalable Privacy pilot site
3. AOB

   1. Identity Assurance Landscape

   2. Anil John’s blog

4. Adjourn

Attendees

• Allan Foster
• Sal D'Agostino
• Steve Olshansky
• Rainer Hoerbe
• Keith Hazelton
• Leif Johansson
• David Chadwick

Quorum is 6 of 11 as of 20 November 2012

Non-Voting

• Ken Dagg
• Nicole Harris
• Ken Klingenstein

Staff

• Heather Flanagan (scribe)

Apologies

Minutes

• Previous call not at quorum; no minutes to approve

Administration

Action Items

New Action Items

Discussion

• Roadmap
  
  • Ken Dagg: Gov't of Canada particularly interested in the Attribute Handling best practices; there are about 180 agencies in the gov't that are almost handling attributes the same; assuming this document is about the SP's handling
  • we will need to put a paragraph or two around each to make sure we know what each doc in the roadmap is expected to cover
    
    • Ken Dagg will volunteer for Attribute Handling Best Practice description
    • Keith Hazelton will volunteer for Context description
  • David Chadwick: in the doc from Andrew Hughes, where is credential validation done?  Ken K - that's probably a deep hole that we'll want to get to later in the call? Ken D - this is a draft document, informed by about 4 people, and in the last few days more activity has happened with Anil's blog encouraging more discussion
  • Leif Johansson: query for Ken K with the trust broker work, should that be a criteria based approach, something that is auditable with something like the IAF?  Asking since Ken K is so involved in the NSTIC view of things
    
    • Ken K: not looking at this in the model he's working on; working on a metaphor or language so we can have the conversation
    • Leif: assuming Ken D might have a different perspective? Ken D: an attribute broker best practice will be more at a policy level, an attribute broker is a way forward and there is probably a similarity between an attribute broker and a credential broker; want to make sure the operations around an attribute broker are operationally supportable (repeatable, do-able)
    • Allan: the issue of an IdP being separate from the attribute provider are starting to raise questions around privacy issues around IdP not knowing which attribute provider the user is going to, so the general discussion has been in defining what framework the attribute provider can work in that is separate from the IdP
  • Leif: is this group focused on SAML, or are we looking at other technologies, or are we entirely technology agnostic?
    
    • Ken K: technology agnostic, though once we get a sense of flows, some of those might be technology dependent; once we have a sence of that, will start to look at what else might be flowing besides trust and attributes; will label the flows in greater detail, such as listing the bundles that would be moving around in various use cases and scenarios
    • Ken D: agree, technology agnostic, and once we agree with what the problem is, we can get further in to the technology component
    • Leif: expected this answer, but deployability and scalability will be greatly informed by technology; should be aware of that even as we start as being technology agnostic
    • Rainer: we definitely need to support multiple technologies, so starting as technology neutral is good

• Trust and Attribute flows (Ken Klingenstein) - see slides on Scalable Privacy pilot site
  
  • also working on an Internet-Draft through the RFC Series on attribute design best practices; attribute design and attributes in motion should relate
  • we want to spend a limited amount of time on this call and maybe one or two more call around the description of the objects in the ecosystem are good enough for now (clarification is good, word smithing is bad)
  • what other flows do we want to think about in the ecosystem?  maybe liability?  note that the technology may impact the flows
  • Leif: not sure where/how/if you want to represent this idea, but the concept of notaries or independent observers of attributes - that might be a way to get around the limitations the inbound representation of attributes to represent provenance and trust; if we can introduce authorities of state, that might help; they won't prevent bad things from happening, but they will let you know when bad things happen; these won't manage attributes direction, but metadata
    
    • Ken K: are they characteristics of the flows, of objects, something else? this is a very important construct - does it exist in the other discussions happening such as with Andrew Hughes' diagram?
    • Keith: there is some flavor of that in the UMA world,
      
      • Leif: though in UMA that is a gating component, it is in-band with attribute flows; Leif is talking about an entity outside the flows, not a gating component
    • Ken K: at this point we may have 4 separate diagrams to chase down
    • Ken K: will add notaries as a place holder for this idea in his diagram
    • Sal: look at the core protocol flow diagram in UMA to get some information to inform this
  • another thing that's going to make this interest is the potentially dynamic nature of trust flows as exemplified by the work being done in the NSTIC pilot by Resilient
  • if we can take our favorite use case and create a diagram the attribute flow and associated metadata flow, that would help
  • Keith: what does "Representative" icon mean? this is the entity that will act as guardian for young/old/someone, someone that can act on behalf of others
  • Feedback from group:
    • Leif: would try to turn these diagrams in to semantic diagram, with each arrow representing a sentence; tease out the statement you want to be true, then the diagram becomes easy to read
    • Keith: agree, the arrows need more than labels; we need to understand how these things are functioning in a semantic sense
    • Ken: so, hearing that this could be useful, need more conversation
    • AI: Keith to create a semantic diagram that will look something at a historical perspective
    • AI: Leif will create a simple semantic diagram on one of the simple flows

Next Call

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