AIMWG telecon Notes 2012-12-11

Date and Time

• Date: Tuesday, 11 December, 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 times - results of doodle poll: 7:30 PT / 10:30 ET / 15:30 UTC every second Wednesday starting 9 January 2013
   4. Call for nominations
      
      1. Chair - 1 nomination = Allan Foster
      2. Vice-Chair - 1 nomination = Sal D'Agostino
2. Discussion / Action Item Review
   
   1. Attribute ecosystem - see Reference Docs on the bottom of the Scalable Privacy wiki page @ Internet2
      
      1. Discussion of Attribute Ecosystem issues
      2. Attribute Ecosystem slides
      3. Attribute Design Considerations I-D
3. AOB
4. Adjourn

Attendees

• Steve Olshansky
• Allan Foster

Quorum is 6 of 11 as of 20 November 2012

Non-Voting

• Ken Dagg
• Ken Klingenstein
• Sal D'Agostino
• Keith Hazelton

Staff

• Heather Flanagan (scribe)

Apologies

Minutes

• Previous call not at quorum; no minutes to approve

Administration

• 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
• Nominations
  
  • will send out an e-vote immediately after this call

Action Items

New Action Items

Discussion

Attribute ecosystem - see Reference Docs on the bottom of the Scalable Privacy wiki page @ Internet2

1. Discussion of Attribute Ecosystem issues
2. Attribute Ecosystem slides
3. Attribute Design Considerations I-D

Beginning with the attribute ecosystem slides, and from there we can go a bit in to the discussion topics.

will be able to easily show 2 kinds of flow (and eventually more) : flows of attributes as distinct from flows in trust about the attributes; the slide deck will continue to evolve as we explore different aspects of the environment

• pay particular attention to slides 2 & 3 (high level elements and first stab at definitions) - is anything missing from this list of elements, and can we wordsmith the individual framing of terms?
  
  • KD: would like to introduce a difference between User (individual asserting attrib about a Subject) and a Subject (to whom attributes relate); in situations of powers of attorney where people are acting on behalf of others, it becomes very confusing to try and determine who we are talking about if we just have "User"
  • KK: not every user will need a Subject defined, so would need to go to the attribute ecosystem and have a bunch of users in the overall big picture, and then a few users with a subject associated with them; does Guardian also capture this idea?
    
    • KD: only case where that might not be true is in Law Enforcement, where a Law Enforcement official may be dealing with a Subject who is not a Guardian
    • SteveO: is the concern that if we use a term like "Agent" that would devolve in to too many rat holes?
• next thing to happen in this space will be for Ken K. to create flows in this ecosystem; we know that attributes are flowing in this ecosystem, and so is trust; there are also consent flows which may (or may not) be the same as trust; in both cases (trust and consent), data and metadata are both flowing along similar paths
  
  • note the last slide, "Decomposing Google" as a way to describe how one player may have so many roles
  • we should train ourselves not to just say "Google" when we're talking about this stuff, but talk about the specific role that Google would otherwise be playing in the discussion
  • where a company's business model depends on them filling multiple roles, it could show some interesting ways a business is encouraged to encroach on boundaries they otherwise shouldn't
• Discussion Topics
  
  • there is an attribute design doc for how you would create attributes for a multi-vertical federation and which will likely be published through the Independent Submissions stream of the RFC Series
  • are there two rough categories, creation and revocation? then there is the transport of an attribute from where it is minted to elsewhere; primary motivator for Ken K is the minting of anonymous credentials a la ABC4Trust model; mechanisms are needed to move attributes around - there are some protocols (SAML, JSON) which starts this work, but more is needed
  • Is this the direction the group wants to move their discussion?  yes, definitely
  • Note that the perspective seems to be that of an IdP; would like to also look at this from the client/end-user perspective; in some cases, attributes are asserted by clients, and then the service provider has to verify those attributes against an authoritative source; then there is the question of how they can store it for reuse later; the whole idea of looking at it from a client-centric point of view
    
    • good idea to come up with 3-4 different ways to partition this space from different perspectives; what kind of categorization would make sense?
    • All the same elements will be there, it's just how one looks at them
    • what do we say about downstream/secondary use of attributes?  in classic IdP space, we stop at release of info to initial RP and rely on a Code of Conduct to prevent anything further, but we don't do anything that looks like DRM of attributes; in the attribute ecosystem diagram, how do we want to deal with downstream use?
      
      • this is where the UMA mindset and their concepts come in
      • when we are talking about intermediaries caching attributes, don't we run in to issues akin to a revocation list? if you are relying on a cached attribute, how do you know it is still valid?
      • this is a big topic, from an attribute broker perspective too; the consumer can trust the data but doesn't necessarily know (or want to know) where it came from - there are some things here that start coming in esp. when start talking federal government and one department not wanting to know what another department is doing
  • if we were to say "LoA of attributes" what are the many things that would depend on? it's not just the assignment of value, it's other actions that could/would happen in the chain of custody for that attribute (i.e. how faithful was the transport mechanism, if this went through an account-linking service, for instance?)
  • what would Kim's Law of Identity look like if applied to Kim's Law of Attributes? minimal disclosure for constrained use could be an interesting double-bind
    
    • UMA world: their "binding obligations" work might be applicable in this space

• We will have this WG focus on a number of issues today, particularly any overlap or gaps, which hopefully will be a short term activity that will then define longer term activities which may or may not happen in this group (i.e. if they are standards-forming)
  • this will also likely feed the IAWG and how they should incorporate attribute considerations in to the IAF

Any Other Business... Adjourn

14:03 PT

Next Meeting

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