AIM WG Notes 17-Apr-2013

Date and Time

• Date: Wednesday, 17 April 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 20-Mar-2013
2. Discussion / Action Item Review
1. Status of the OIX work (Sal)
2. Cross-analysis of the various protocols e.g. an OpenID Connect approach versus a SAML based approach versus UMA etc (Keith)
3. Latest in flow diagrams (Ken)
3. AOB
4. Adjourn

Attendees

• Keith Hazelton
• Allan Foster
• Matt Tebo
• David Chadwick
• Kirk Fergusson

As of Mar 20, 2013, quorum is 6 of 10

Non-Voting

• Ken Klingenstein
  

Staff

• Heather Flanagan

Apologies

• David Coxe

Minutes

• Minutes not approved; call not at quorum

Administration

Action Items

New Action Items

Discussion

Cross-analysis of the various protocols e.g. an OpenID Connect approach versus a SAML based approach versus UMA etc (Keith)

• See working diagram: WG - Attributes In Motion - Comparison of Protocol-based Solutions by Decomposition into Atomic Functions
• Started as one of the NSTIC pilot efforts; there will be solutions proposed that rely on drastically different protocol stack and protocol models
• Q&A
  
  • Is this a useful effort? Is this a problem that needs to be solved?
    
    • definitely on to something here; the trust framework adoption process has the notion of comparability - they look at different IdPs and the processes against 800-63 and use that to determine LoA; like the idea of using a table like this to help define comparability; trick is that the process only applies to IdPs that have an authN model that align neatly with 800-63; looking at the side-by-side comparison, row 2, 800-63 doesn't talk about authorization and provides no guidance, so how could we compare these things?  This isn't a fault of the table, it's a fault of 800-63
    • One of the challenges entering to this is that LoA is a multifaceted attribute, and one service may have multiple LoA depending on the component
    • if UMA broke up their components in to smaller functional components, could see how to use federated authentication in SAML
  • is there another column we could create around anonymous credentials and how they unfold, or is it a subset of existing cases?
    
    • if you wanted to bring anonymous credentials in, you'd have to create a use case of non-associability and then we could pose solutions that would have to use anonymous credentials or include some kind of obfuscator
  • is there a difference between an attribute verifier and an attribute provider?  is there a substantive difference between a service that collects information and has the info verified, versus having the user direct the service to something that just provides verified attributes?
    
    • there may be differences in consent
    • an attribute verifier allows for a more privacy-respective architecture
  • is there room for any additional kinds of columns? 
    
    • absolutely, there are probably many stacks out there competing for space and different mixes and matches to the space
    • we should develop the comparisons only when someone puts a concrete proposal on the table, otherwise it's too big an effort; need real not hypothetical use cases

Latest in flow diagrams (Ken)

• Ken uploaded a new diagram on to the Scalable Privacy site on Internet2's wiki; still in progress and more thought needs to go in to it regarding verifier vs. provider and how metadata should be included
• there is now a very long set of use cases listed on the IDESG secretariat wiki; there is no structure among the use cases, so some of the use cases we are dealing with like GPII would apply to all of the use cases as a second layer; regardless of the nature of the transaction you are trying to conduct, there would be an accessibility angle on top of it to ensure that all the stuff in the use case is being presented to the users in a way that meets their needs
• we have been trying to figure out how to bring attributes in to those use case conversations, and thinking about a registry of attributes
  
  • recently got a new set of attributes from the FICAM crowd; something from the VA Motor Vehicles department; the National Association of State CIOs have identified NIEM as a citizen-centric schema
• starting to look at the metadata people are trying to capture about these attributes; what would be the most concise set of metadata that would be of value?
• there is a hint that some states will be using their motor vehicle departments as an attribute verifier; the goal is that the attribute provider does not know when things are being verified
• InCommon is coming up with a second certification mark that will be very privacy preserving
• Haven't seen many use cases where you want privacy and you do NOT want statefulness
• There will be more on this at the upcoming IIW in May
• Some of this was triggered by FICAM postings by Anil about provisioning by third party to the US gov't
• it would be nice if the flows of trust were the same whether it was an anonymous or federated credential; how would we UMA-esque an anonymous credential?
  
  • David Chadwick has a PhD student who has been working on metadata flows for the last 3 years; the question is how to grow a federation in an organic manner

Status of the OIX work (Sal)

• To be covered on the next call

AOB

• Allan - looking for a volunteer to act as Secretary for the group to help with minutes and quarterly reports

Next Call

• Date: Wednesday, 1 May 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