AIM WG Minutes 21-August-2013

Date and Time

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

Agenda

1. Administration:
   
   1. Roll Call
   2. Agenda Confirmation
   3. Approval of Minutes: AIM WG Minutes 07-August-2013
2. Discussion / Action Item Review
   1. Further discussion of WG - Attributes In Motion - Roadmap Planning - AIMWG and assigning shepherds (Ken Dagg, Colin Wallis)
   2. Attribute registry requirements draft: http://tools.ietf.org/id/draft-johansson-areg-reqs-01.txt (Leif Johansson, Heather Flanagan)
   3. Periodic Table of Trust Elements (Ken Klingenstein)
3. AOB
4. Adjourn

Attendees

• Steve Olshansky
• Allan Foster
• Keith Hazelton
• Sal D'Agostino

As of August 5, 2013, quorum is 3 of 5

Non-Voting

• Maarten Kremers
• Ken Dagg
• Leif Johansson
• Colin Wallis
• Colin Soutar

Staff

• Heather Flanagan (scribe)

Apologies

Minutes

• Propose to approve the minutes of AIM WG Minutes 07-August-2013 - Allan Foster moves, Keith Hazelton seconds, minutes approved

Administration

Action Items

New Action Items

Discussion

Attribute registry requirements draft: http://tools.ietf.org/id/draft-johansson-areg-reqs-01.txt (Leif Johansson, Heather Flanagan)

• there was a similar exercise a few years back when Leif helped establish an IANA registry for Levels of Assurance (http://www.rfc-editor.org/rfc/rfc6711.txt)
• we've seen several attempts at building internet-scale registries, so it is recognized as not an easy activity
• so, rather than start the registry itself, we are trying to spec out the requirements, isolating that discussion from how to represent the information or how to build the registry
• we have not received a lot of comments on this so far
• why was this an Internet Draft at all? for an attribute registry to work, it needs to be anchored to some existing organization or process that manages internet-scale registries, and there are only 2 - IANA and ICANN; if you want to set up a registry with these organizations, you need an RFC
• the document tries to make a logical, structured approach, the architectural aspects not the representational aspects
• Discussion:
  
  • there seems to be a few efforts; everyone who enters in to the attribute space seems to understand we need to have a dictionary, lexicon on what the attributes actually mean.  In this group, we've talked about the concept of metadata around attributes, because agreeing to the meaning of the attribute itself is only one aspect of understanding the attribute.  Levels of trust, context, more all fit in to actually understanding an attribute and how it could/should be used.  Is there space in the registry for this metadata?
    
    • Yes.  Identified as something that needs to be done, probably in parallel to the creation of the registry itself
  • when the document first came out, was fairly excited and surprised it got no traction because it is obvious that it is needed.  Still hoping this moves ahead, because the need has not gone away.
    
    • registries are a can of worm in many communities, because they imply a central point of control.  We are not trying to standardize on attribute semantics, we are trying to standardise on descriptions.
  • this is also a work item in the Scalable Privacy NSTIC grant.  They have started building data structures and compiling information, and while not going through the IANA registry process, it is something to start collecting the information.  Putting on the table what kind of information needs to be represented.  The native format they've come up with is an attribute registry based in an ontology tool (OWL).  But remember there are 2 tracks, the meta issue of whether we should do the registry and if so what are the requirements, and two, start doing the work to put it together.  This draft touches on the former, the Scalable Privacy grant focuses on the latter.  The administration has to be distributed somehow; Scalable Privacy is pulling it in from other specs.
  • this is a requirements doc - are there any requirements missing?
    
    • it depends on what the next steps look like.  Depending on how we want to talk about issues of metadata, for example, might muddy the waters. 
    • Discussing this in multiple communities is one important thing we need to do.  We could set up a common set of interfaces and APIs, just build it and they will come without requiring IANA.  However, if we want to run the registry as a central point of information, then we need to see if we have support for this in the internet community.  There are also processes for that within the IETF itself (Area Director support, possibly an IETF WG) that we will have to take in to account
  • what about the nay sayers?  what would they find problematic here? 
    
    • either you build something completely centralized, at which point people can't completely agree with and so will not use; or you build a non-centralized thing which turns in to a majorly complex entity requiring global discovery services.  OIDs are an example of the kind of complexity we're looking at.
    • the utility of attributes is going to directly relate to people being able to discover them, so this is really important enough to try
  • there is a fairly open space with respect to attributes; we know we need to understand what we're talking about if there is going to be real interaction, but nothing leaps forward as the obvious way to do things.  Setting up a registry is one path, but the registration path seems fairly arbitrary.  There is not an alternative - probably no single "right path" - so we need to do something.  Do still wonder what the role the additional metadata will play in the registration, since it is more than just the definition that needs to be defined.
    
    • that is probably a separate document (to describe the metadata); create a strawman metamodel and then a registry that can handle anything thrown at it as long as there are a few core facts (a name, an owner, that kind of thing)
• What are the next steps?
  • from this community, we would like answers to the questions in the documents - there are a number of choices in the document, and say "if I were to build one of these things, I would prefer A over B, C over D"
    
    • Keith to provide his answers based on the work done in the Scalable Privacy work and will send that to the list; Allan will also go through and answer the questions as well
    • remember it is equally important to talk about what is missed, if something is obvious as you go through it
  • need to think about what other parts inside Kantara should look at this; maybe IAWG and FIWG should look at this as well
    • let's keep it within the group until we've solidified some of what we've talked about today, then socialize with the other groups

Further discussion of WG - Attributes In Motion - Roadmap Planning - AIMWG and assigning shepherds (Ken Dagg, Colin Wallis)

• One of the things that came out of the Kantara Leadership retreat was the question of Why does Kantara exist and how to the WG support that effort
  
  • the draft "why" = "Kantara exists to define rules of engagement for operators of online services, enabling high-value, privacy-preserving identity and access."
• There is a split between the Innovation side (WG/DG) and Service side (Accreditation services) was also recognized, and for the WG, we need to make sure the WG are in line with the "why" behind Kantara.  The output of the WG should ultimately be tools that Kantara can use for that overriding reason for existence.
• We will be looking at the charter again, which does seem to be fairly in line with the "why", and in our charter we have 3 documents slated to be completed. We need to get something started on those documents.  Does anyone have a convenient framework of skeleton document for the Best Practices doc?  (silence)
• Encourage everyone to take a look at the roadmap, decide if they can provide resources to help move this forward; we need to pull in some of that work from AMDG as work items for this group
• Heather to volunteer purely as a volunteer to help get the Best Practice document started
• Sal to give a background perspective to the list

Periodic Table of Trust Elements (Ken Klingenstein)

• another wonderful piece of work from the academic community! 
• Will come back to this on the list and the next call

Next Call

• Date: Wednesday, 21 August 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